この記事は、「Model Context Protocol(MCP) Advent Calendar 2025 12日目」の記事です。

チーム開発で CircleCI のパイプラインがエラーを起こすと、原因を調べるためにブラウザでダッシュボードを開き、失敗したジョブのログを確認して、コードエディタに戻って修正する。このようにウィンドウやタブをいくつか切り替えながら修正作業を行う必要があります。そしてなんとなく「そういうものだ」と思いながらやりがちですが、このようなコンテキストスイッチは思いのほか時間がかかるものです。

今回はCircleCI MCP サーバーと Cursor を組み合わせてIDE 上で作業を完結させる方法を試してみました。特に今回はレビュワー視点を意識し、「別の開発者による実装で CI が失敗した場合の対応」にフォーカスしてみています。

Cursor Agentsに開発させ、CircleCIで実装を検証する

今回は自分でコードを書くのではなく、チーム開発やAIコーディングエージェントを利用しているケースを想定します。そこで Cursor Agentsを利用してコードを変更させ、GitHubにPull Requestを作成させるフローを準備しました。npm create viteでセットアップしたシンプルな JavaScriptベースのカウンターアプリに、「カウントの数字が素数なら、表示を変える」という機能を実装させています。

CIパイプラインで自動テストを行わせるため、「kent beckの提唱するTDDで開発しろ」とプロンプトに追加しています。DOMを操作しながらの結合テストに近い形ではありますが、Cursor Agentsはテストファイルの作成や更新まで自動で実施してくれていました。

作業が終わると、GitHubリポジトリに新しいブランチでpushが行われ、Pull Requestが作成されたことをトリガーにCircleCIのパイプラインが実行されます。もしパイプラインの中に定義されたテストやリント・ビルドなどのジョブが失敗した場合、以下のようなメールがCircleCIから送信されます。

この例では、E2Eテストのジョブが失敗していることがわかります。通常、このようなメールを受け取った後は、CircleCIのダッシュボードにログインし、エラーの詳細などを調査する必要があります。そしてその後IDEでPull Requestのコードをチェックアウトし、ログに基づいた原因調査を始める流れとなります。この時点でIDEとCircleCIダッシュボードの２ウィンドウを開くことになります。

今回、コンテキストスイッチのコストを削減し、PCのウィンドウを綺麗にするため、Cursor IDEとCircleCI MCPサーバーの２つを組み合わせて１ウィンドウだけで原因調査から修正までの作業を完結させる方法を試します。

CircleCI MCP と Cursor IDEで１ウィンドウで調査から修正を実施する

ここからはCircleCI MCPとCursor IDEを組み合わせた作業について紹介します。なおセットアップ方法については、以前作成したブログ記事を参考に実施してください。

先ほどのCircleCIから届いたメールから、「パイプラインが Fail したブランチ名」をコピーしておきましょう。その後、Cursor IDEを開きます。そして「<ブランチ名>ブランチのCIパイプラインがfailしている。問題を調査して修正しなさい」のようなプロンプトを送信しましょう。もしこの際、いきなりコードを変更させるのではなく、事前に修正計画を立てさせてそれをレビューしたい場合は、Cursor Planモードを利用することをお勧めします。

プロンプトを送信すると、Cursorがまず対象のブランチをremoteからcheckotuします。

そしてCircleCI MCPサーバーを利用し、パイプラインのどのジョブが失敗したかや、その理由について情報を収集します。

問題が特定できた場合、Agentモードで実行しているならばコードの修正までそのまま実施してくれます。

Cursor Rulesを活用して、CIパイプラインが成功したかも自動監視させる

以前作成したブログ記事に紹介しているCursor Rulesを設定している場合、git pushをCursorに実施させてみましょう。Cursor Rulesの指示に従い、CircleCIのパイプライン・ジョブが全て成功するかを監視してくれます。ここでもし別の問題が見つかった場合は、再び原因の調査と修正作業を実施してくれます。

このように「メールを見て、CircleCI MCPの接続されたIDEに相談したらOK」という非常にシンプルなフローで一時調査ができるようになりました。もちろんコードの修正までそのまま実施させることもできますし、GitHub MCPやSlack MCPを接続していればPRへのコメントやSlackへのメンションとして実装者へのフィードバックを出すことも可能です。

このようにIDEとCIをAIで接続させることで、開発フローの中で発生する予期せぬトラブルへの初動対応や調査をできるだけ少ないステップ数で実施できます。もしチームメンバーから「CI が失敗しているんだけど、見てもらえますか」と助けを求められた場合でも、手元の IDE から簡単に調査と修正がシームレスに完結します。また、DevinのようにMCPサーバーを利用できるコーディングエージェントを使っている場合であれば、そもそも「CIのFailを検知して調査を指示する」というステップすらAIエージェントが自発的に実施してくれます。

ポイントは、「開発者として集中したい作業にかける時間をどれだけ確保できるか」だと思います。CircleCIやCircleCI MCPサーバーのような存在は、「重要だしやらないといけないけど、プロダクトやサービスの新たな価値提供にはつながらない作業」を自動化・半自動化できるチャンスです。

小さな改善、小さな変化かもしれませんが、このようなMCPサーバーやサービス連携機能を活用して、少しでも差別化につながらない重労働の削減に役立てば幸いです。