Bitrise MCPをClaude Codeにつないでビルド起動と失敗調査を任せる

Bitrise MCPサーバーをClaude Codeに追加すると、モバイルアプリのビルド一覧の確認、失敗ログの読み取り、ビルドの起動、アーティファクトの確認を会話から頼めます。リモートサーバーに1行で接続でき、認証はBitriseアカウントへのブラウザ サインインで済みます。トークンのコピーは要りません。

このページでは接続、調査の流れ、ビルド起動、アーティファクト、権限の絞り方を順に扱います。

接続は1行、認証はOAuth

Bitrise MCPには、Bitrise側が運用するリモートサーバー(Streamable HTTP)と、手元で動かすローカルサーバー(Go製)があります。READMEのClaude向け手順は、リモートサーバーを推奨しています。

プロジェクトのディレクトリでClaude Codeを開いておくと、設定の範囲が分かりやすくなります。次のコマンドでサーバーを追加します。

claude mcp add --transport http bitrise https://mcp.bitrise.io

追加後はClaude Codeを再起動します。最初にツールを使う場面でブラウザが開くので、Bitriseにログインして同意画面を承認します。最後に確認します。

claude mcp list
claude mcp get bitrise

OAuthに対応していない古いClaude Codeを使っている場合や、トークンで運用したい場合は、個人アクセストークン(PAT)をBearerヘッダーで渡す方法もあります。トークンはBitriseのアカウント設定のセキュリティ画面で作ります。

claude mcp add --transport http bitrise https://mcp.bitrise.io \
  -H "Authorization: Bearer YOUR_BITRISE_PAT"

トークンをコマンドに直書きしたくない場合、READMEは.envに保存して.gitignoreへ.envと.mcp.jsonを追加する方法を例に挙げています。

ローカルサーバーを選ぶ場合

ローカルサーバーはstdioで動き、認証はPATのみです。Go 1.25以上が必要です。

claude mcp add bitrise -e BITRISE_TOKEN=YOUR_BITRISE_PAT \
  -- go run github.com/bitrise-io/bitrise-mcp/v2@v2

--より後ろがサーバーの起動コマンドで、手前の-eなどはClaude Code自身のオプションです。Claude Codeの他のstdioサーバーと同じ書き方です。

設定の置き場所を選ぶ

claude mcp addの保存先は、既定では現在のプロジェクトだけに効くlocalです。-s userなら全プロジェクトで使え、-s projectなら.mcp.jsonでチームに共有されます。PATをヘッダーに入れた設定をprojectスコープで共有すると、トークンがリポジトリに入りかねません。共有するならOAuthの構成にして、.mcp.jsonにトークンを書かない運用が安全です。

使うツールを絞る — API groupとread-only

Bitrise MCPは、全部入りだとツール数が多くなります。READMEのtools.mdには、アプリ、ビルド、アーティファクト、アウトゴーイングWebhook、キャッシュ、パイプライン、ワークスペース、リリース管理、CodePush、Insightsなど、多くの分類(API group)のツールが載っています。

絞り込みの指定先は、サーバーの種類ごとに2つあります。

指定できるグループ名はapps、builds、workspaces、outgoing-webhooks、artifacts、group-roles、cache-items、pipelines、account、read-only、release-management、configuration、release-management-code-push、insightsです。指定しなければ全グループが有効です。

read-onlyグループは名前のとおり、一覧や取得だけのツールにそろえる指定です。tools.mdの対応表では、list_builds、get_build、get_build_log、get_build_stepsなどにread-onlyの印が付いています。失敗調査だけを任せるなら、ここから始められます。リモートサーバーにヘッダーを足す場合は、例えば次のような形になります。

claude mcp add --transport http bitrise https://mcp.bitrise.io \
  -H "x-bitrise-enabled-api-groups: read-only"

この例は、ヘッダー指定(tools.md)と-Hの書式(Claude Codeのドキュメント)を組み合わせた書き方です。ヘッダーを付けてもOAuthのサインインが必要かどうかは、手元でclaude mcp get bitriseと最初のツール呼び出しで確かめてください。

失敗したビルドを調べる

READMEの例には「直近の失敗したiOSビルドを表示して、失敗理由を説明して」「mainブランチのビルド成功率を過去1週間で出して」といった依頼が載っています。この調査を、ツールの動きに分解するとこうなります。

list_buildsのstatusは数値で、0が未完了、1が成功、2が失敗、3が中止、4が実行中です。依頼文に「失敗したビルド」と書けば、Claudeがこの値を選びます。ただし挙動を固定したいときは、次のように条件を明示すると安定します。

Bitriseのアプリ「MyApp」のmainブランチで、失敗(status 2)したビルドを新しい順に3件出して。
一番新しいものについて、失敗したステップと、ログ中の最初のエラー行を示して。
bitrise.ymlの該当ステップの設定も添えて。

app_slugはアプリのIDなので、最初に「アプリ一覧からMyAppを探して」と頼むと、Claudeがlist_appsを使って特定してくれます。

get_build_logが実際に返す量やページングの有無は、READMEのツール一覧に記載がありません。大きなビルドで試すときは、ログ全体を期待せず、まずget_build_stepsで落ちた箇所を絞ります。

ビルドを起動する

trigger_bitrise_buildは、アプリを指定して新しいビルドやパイプラインを起動するツールです。引数は次のとおりです。

これに加えて、environmentsでこのビルド限りの環境変数を渡せます。各要素はmapped_to、value、任意のis_expandを持つオブジェクトです。

失敗の原因がXcodeのバージョン差だと疑うときは、stackを変えて同じコミットを再実行できます。bitrise.ymlを書き換えずに試せるのが利点です。

さっき調べた失敗ビルドと同じコミットで、スタックだけosx-xcode-16.0.xに変えて
workflow「primary」を再実行して。起動したら、ビルドのslugを教えて。

起動後の経過は、get_buildで状態を、abort_buildで中止(理由をreasonに付けられます)を行えます。パイプラインについては、rebuild_pipelineやabort_pipelineのツールがあります。

ビルドの起動は、Bitrise上で新しい実行を作る書き込み操作です。自動で走らせる前に権限設定で確認を挟む構成が考えられます。設定例は後半の「権限を絞る」にあります。

アーティファクトを確認する

list_artifactsはビルドごとのアーティファクト一覧を、get_artifactは1件の詳細を返します。ビルドのslugを指定して、そのビルドが生成したアーティファクトを探せます。

注意したいのは書き込み系です。

• delete_artifactは、アーティファクトを削除します
• update_artifactは、is_public_page_enabledで公開ページを有効にします

tools.mdはupdate_artifactについて、インターネット上に公開のインストールページを作る操作としてopenWorldHintがtrueになると説明しています。アーティファクトの公開を、会話の流れで誤って頼まないよう、この2つは許可リストに入れない扱いがよいでしょう。

テスターへの配布やCodePushなど、リリース管理系のツールは別グループです。tools.mdは、appsグループとの混同を避けるため、release-managementは単独で使うことを勧めています。

Insightsでビルド傾向を見る

insights_get_build_totalsは、期間内のビルド数、失敗率、所要時間のp50/p90、合計時間を返します。insights_get_build_seriesは同じ指標を時系列で、insights_list_flaky_testsは再実行で結果が変わった不安定なテストを順位づけして返します。

制約が2つあります。

• Insights APIは有料のInsightsプランが前提で、プランがないワークスペースでは全呼び出しがHTTP 402で失敗します
• 1回の問い合わせは1つのプロジェクトが対象で、workspace_slug、project、start、endが必須です

READMEの「mainブランチの成功率を過去1週間で」という依頼は、この系統のツールで答える種類の質問です。

権限を絞る — 読み取りは通し、起動は確認する

Claude Codeの権限ルールは、MCPツールをmcp__<サーバー名>__<ツール名>で指定します。サーバー名はclaude mcp addで付けた名前なので、この記事の手順ではbitriseです。allowルールのワイルドカードは、mcp__bitrise__*のようにサーバー名を書いたあとにだけ使えます。

読み取り系は許可し、ビルド起動は都度確認、破壊的な操作は拒否する設定は、例えば次のような形になります。

{
  "permissions": {
    "allow": [
      "mcp__bitrise__list_builds",
      "mcp__bitrise__get_build",
      "mcp__bitrise__get_build_steps",
      "mcp__bitrise__get_build_log",
      "mcp__bitrise__list_artifacts"
    ],
    "ask": [
      "mcp__bitrise__trigger_bitrise_build",
      "mcp__bitrise__abort_build"
    ],
    "deny": [
      "mcp__bitrise__delete_artifact",
      "mcp__bitrise__update_artifact",
      "mcp__bitrise__delete_app"
    ]
  }
}

ツール名はtools.mdのものです。MCPツールのルールに括弧でパラメーター条件を付けても、Claude Codeは読み込み時にそのルールを読み飛ばします。「mainブランチ限定でビルド起動を許可」のような条件は書けないので、起動はaskに置いて、人が毎回確認する運用になります。権限ルールの確認と編集は/permissionsコマンドでもできます。

API groupの絞り込みと権限ルールは役割が違います。前者はClaudeにそもそもツールを見せない手段で、後者は見えているツールの実行可否を決める手段です。両方を重ねると、誤操作の余地が小さくなります。

つまずいたとき

接続自体の切り分けは、MCPサーバーに接続できないときの切り分け手順の4層の考え方がそのまま使えます。

Claude Desktopで使う場合は、設定ファイルにリモートサーバーを書くか、mcp-remoteをアダプターとして挟みます。npxが見つからないときはenvのPATHでnpxの場所を指定します。

他のCIツールのMCPとの違い

CIの失敗診断をClaudeに頼む型は、他のサービスでも同じです。CircleCI、Buildkite、Jenkinsの記事にも、接続と診断の手順があります。Bitriseで目立つのは、ビルド単位のスタック上書きと、bitrise.ymlをビルドごとに取れる点です。Xcodeの版違いを疑う場面では、この2点が使えます。

まとめ

最初はread-onlyグループで接続し、失敗ビルドの調査だけを任せるところから始めると、ビルドの起動やアーティファクトの公開といった副作用のある操作を後から段階的に足せます。起動系は権限ルールのaskに置き、削除と公開はdenyにしておけば、会話の流れで意図しない操作が走る余地を小さくできます。