Devin を使った開発において、CI の結果確認は重要なフィードバックループの一つです。
しかし、通常 Devin は CI の失敗の検知まではしてくれますが直接 Buildkite の情報にアクセスして CI の失敗原因を確認するところまではやってくれません。 CI の情報をベースにした修正を依頼するためには人間が介入する必要があり、自律的な問題解決が難しくなります。
この記事では、Buildkite MCP Server を Devin にセットアップする手順を紹介します。 これにより、Devin が自律的に Buildkite のビルド状況やログを確認できるようになります。
Buildkite MCP
Buildkite MCP はリモート MCP サーバーとローカル MCP サーバーで提供されています。
リモートの方は事前に MCP サーバーをローカルにインストールしておく手間が省けて便利ではありますが、Buildkite MCP は Buildkite アカウントでログインしているブラウザから認証を行う方式のため(おそらく)Devin のようなリモートサーバーで処理が行われるエージェントでは利用できません。
そのため今回は Devin のローカル環境で Buildkite MCP の Docker 版をホストして利用する方法をとりました。
セットアップ手順
1. Install Dependencies で Docker Image を Pull
まずは Devin のローカル環境に Buildkite MCP の Docker イメージをインストールするため、Devin's Machine の「Install Dependencies」セクションで Buildkite MCP Server の Docker イメージを取得します。
docker pull buildkite/mcp-server
これにより、次回以降の Devin セッション起動時にも Docker イメージが利用可能な状態になります。
参考: Buildkite MCP Server ドキュメント
2. Secret に Buildkite API key を追加
続いて Devin の Secrets に Buildkite の API key を設定します。
- Buildkite の Personal Settings > API Access Tokens から新しいトークンを作成
- 必要な権限(Read Builds、Read Pipelines など)を付与
- Devin の Secrets 設定から追加
3. MCP Marketplace で MCP Server を登録
Devin の MCP Marketplace から Buildkite MCP を登録します。
MCP Marketplace ではさまざまな MCP が必要な設定がされた状態で公開されており、使いたい MCP を選んで利用できますが、Buildkite MCP はマーケットプレイスで公開されている中にはなく Add Your Own から自分で設定する必要があります。
今回は Buildkite のドキュメントにも記載の以下の docker コマンドを利用するような設定をしました。
登録するコマンド:
docker run --pull=always -q -it --rm -e BUILDKITE_API_TOKEN buildkite/mcp-server stdio

Environment Variables で先ほど設定した Buildkite API key のシークレットの値を BUILDKITE_API_TOKEN 環境変数としてセットしています。
ここまでの設定で Devin が Buildkite MCP を利用できる状態になります。
4. Knowledge に使い方を記載
ここまでの設定で Devin は Buildkite MCP を利用することはできるようになりますが、まだこの状態だと正しくないコマンドで実行を試みたりと安定していません。 Devin が適切に MCP を活用できるよう、Knowledge に使い方を記載しました。
Buildkite MCP Server の使い方
# Buildkite MCP Server の使い方 ## 前提条件 - Devin's machine の設定であらかじめ buildkite MCP の Docker イメージ (`buildkite/mcp-server`) をインストールしておく必要があります - 環境変数 `BUILDKITE_API_KEY` が設定されている必要があります ## 概要 buildkite-mcp サーバーは Docker コンテナとして提供されており、stdio モードで JSON-RPC プロトコルを使用して通信します。 ## 基本的な使い方 ### ビルド情報の取得
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_build","arguments":{"org_slug":"your-org","pipeline_slug":"
### 失敗ジョブのログ取得
echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"tail_logs","arguments":{"org_slug":"your-org","pipeline_slug":"
### 利用可能なツール一覧
echo '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' | \ docker run --rm -i -e BUILDKITE_API_TOKEN=$BUILDKITE_API_KEY buildkite/mcp-server stdio 2>/dev/null
## 主要なツール - get_build: ビルド情報取得 - tail_logs: ログ末尾取得 - search_logs: ログ検索 - list_builds: ビルド一覧 ## 注意事項 - mcp-cli ツールは接続エラーが発生するため、Docker を直接実行する方法を使用 - job_id は Buildkite REST API で取得可能
CI 失敗時の振る舞い
GitHub への push 後に CI の失敗を検知したら、その失敗が Buildkite のものであるかどうかを確認してください。 Buildkite の失敗であった場合は Buildkite MCP サーバーを利用して CI 失敗のログ取得、原因調査、修正を行ってください。
まとめ
Buildkite MCP を Devin にセットアップすることで、CI との連携が強化され、より自律的な開発が期待できます。 特に、CI の失敗時に人間の介入なしで原因を特定し修正できるようになる点は、開発効率の大きな向上につながります。
Devin's Machine の設定と組み合わせることで、ローカルでのテスト実行から CI の確認まで、一貫した自律的な開発フローを実現できます。