テストの失敗は、ソフトウェア開発において避けては通れないものです。壊れた条件分岐、見落とされたエッジケース、直前のリファクタリング——どんなに慎重にコードを変更しても、思わぬ落とし穴はつきものです。とはいえ、その原因を突き止めるために延々とログを追いかけることは、エンジニア本来の仕事とは言えません。
このような課題を、より速く、より効率的に解決できる方法があります。
このガイドでは、CircleCI MCP サーバーを活用して、CI/CD ビルド内で発生したテストの失敗を、エディタ上で特定・解析・解決する方法を紹介します。 CI からのフィードバックを直接開発環境に取り込むことで、コンテキストを切り替えることなく、失敗から修正までをスムーズに進めることが可能になります。
なぜテストの失敗にフォーカスするのか？
テストの出力結果は参考になりますが、生のログだけではすべてを把握することはできません。開発者はビルドログ、ソースコード、ドキュメントを行き来しながら問題の原因を探ることになり、そのたびにコンテキストが切り替わります。こうした積み重ねが、開発効率を大きく損なうのです。
テストの失敗は、チームの足を引っ張り、ビジネスにとってもコストがかかります（関連記事ー英語）。開発の流れが中断されることで、リードタイムの増加、デプロイ頻度の低下、さらにはソフトウェア提供全体のパフォーマンスにも悪影響を及ぼします。
CircleCI MCP サーバーは、こうした課題に正面から取り組むために、IDE 内で動作します。テストスイートが CircleCI 上で失敗した際、エージェントは以下のような対応を自動で行います：
- CircleCI API を通じて失敗ログを取得
- どのテストが、なぜ失敗したのかを特定
- 該当するプロジェクト内のコードを特定
- テストの意図に沿った修正案を提示
わざわざ調査に時間を費やす必要はありません。エージェントに確認するだけで、失敗の原因を洗い出し、特定し、さらには修正の提案までしてくれます。しかも、それらすべてがエディタ内で完結します。その結果、すぐに開発の軌道に戻り、ユーザーに価値を届ける本来の仕事に集中できるのです。
サンプルプロジェクトのセットアップ
CircleCI MCP サーバーの動作を実際に確認するために、意図的にテストが失敗する小規模なプロジェクトを使って説明を進めていきます。これにより、エージェントが実際の CI 出力にどう反応し、テストの意図に基づいてどのように修正を提案するかがわかりやすくなります。
前提条件
以下の環境が必要です：
- 無料の CircleCI アカウント
- GitHub アカウント
- Node.js 18 以上
- MCP に対応した任意の IDE（Cursor など）
環境の準備
アシスタントがあなたの CircleCI データにアクセスできるようにするには、API トークンを使って認証を行う必要があります。
まず初めに、CircleCI のユーザー設定にアクセスし、パーソナル API トークンを新規作成してください。 作成後は必ずトークンをコピーし、安全な場所に保管しておいてください。この後のセットアップで使用します。
次に、作成した API トークンを使って、IDE 側で MCP サーバーの設定を行います。
この手順により、アシスタントがあなたの CircleCI アカウントと連携し、テスト実行に必要なログやステータス情報へアクセスできるようになります。
ステップ 1：サンプルリポジトリをクローンする
まずは、デモプロジェクトのローカルコピーを作成しましょう。このプロジェクトには、単純なロジックバグを含んだ数学関数と、それによって失敗するテストが含まれています。
この最小構成により、MCP サーバーがどのように問題を特定し、アプリケーションの複雑さに惑わされることなく、適切な修正を提案するかを明確に確認できます。
git clone https://github.com/CircleCI-Public/circleci-mcp-cookbook.git
cd circleci-mcp-cookbook/fix-failed-tests
このプロジェクトおよびその他の活用例は、CircleCI MCP クックブック（英語）にて公開されています。
ステップ 2：コードをプッシュして、失敗するビルドを実行する
次に、リポジトリを CircleCI に接続し、実際の CI 環境でテストスイートを実行します。ここでの目的は、MCP サーバーが反応できるように、意図的にテストの失敗を発生させることです。
以下の手順で、最初の失敗ビルドをトリガーします：
- CircleCI 上で新しいプロジェクトを作成し、GitHub のリポジトリと連携させます。
- コードをリポジトリにプッシュ（英語）します。
パイプラインが実行されると、CircleCI がテストスイートを実行します。
このステップにより、関数が誤った結果を返すことで、明確なテスト失敗が発生します。
ステップ 3：コードアシスタントにエラーの修正を依頼する
テストの失敗が確認できたら、IDE を開いてアシスタントとの新しいチャットを開始します。ここから、CircleCI MCP サーバーのサポートが始まります。
アシスタントに次のように依頼します：
fix the failed test in CI
アシスタントは、MCP サーバーを通じて最新のパイプライン実行から、構造化されたテスト失敗ログを取得します。
その後、アシスタントはログの出力を解析し、どのテストが失敗し、なぜ失敗したのかを特定します。 この例では、テストが期待値の 3 ではなく、-1 を返していることを把握します。
次に、アシスタントは失敗の原因をソースコードに遡って追跡します。壊れているロジックを含むファイルを開き、該当する関数の実装箇所をハイライトします。
この時点で、アシスタントは「テストの失敗」と「そのテストが意図していること」の両方を理解した上で、修正案を提示します。
ステップ 4：修正をプッシュしてパイプラインを再実行する
修正内容を確認して問題がなければ、そのまま変更をコミットし、GitHub にプッシュします。すると、CircleCI が自動的にパイプラインを再実行します。
修正が正しく適用されていれば、パイプラインは成功するはずです。
ブラウザを開かずにパイプラインの状態を確認したい場合は、アシスタントに次のように尋ねます：
what's the status of the latest pipeline for this project?
アシスタントは get_latest_pipeline_status ツールを使って、対象ブランチの最新パイプライン情報を取得・要約してくれます。出力例は以下のようになります：
Workflow: build
Status: success
Duration: 2 minutes
Created: 5/01/2025, 10:15:30 AM
Stopped: 5/01/2025, 10:17:45 AM
---
Workflow: test
Status: success
Duration: 1 minute
Created: 5/01/2025, 10:18:00 AM
Stopped: 5/01/2025, 10:19:03 AM
このように、ビルドの進捗や状態を IDE 上で手軽に把握できるため、単一テストの確認から全体のパイプライン検証まで、フィードバックループを高速かつ集中したままで進められます。
より速くフィードバックを得るために
このワークフローにより、エラーの検出から修正までの時間を大幅に短縮できます。CIの失敗に直面しても、ログやテストファイルの海を20分間さまよう必要はもうありません。アシスタントが文脈を理解し、修正をサポートし、次に進むべきステップへと導いてくれるため、開発者は集中を切らすことなく作業を続けられます。
自分の環境で検証してみよう
このワークフローは、10 分で試すことができます：
- サンプルプロジェクトをクローン
- MCP 対応 IDE に CircleCI MCP サーバーをセットアップ
- 意図的に失敗するテストを含む変更をプッシュ
- アシスタントに修正を依頼
失敗から修正まで、たったこれだけで完了します。
今後について
CircleCI MCP サーバーは、開発のスピード向上や反復作業の削減、テストフィードバックの統合を目的に、常に新機能やツールを追加しています。 最新情報は MCP サーバーのリポジトリ や 変更履歴（changelog） で確認できます。また、新しいユースケースや活用ガイドも随時更新されているので、「CircleCI MCP クックブック（英語）」もぜひご覧ください。
まずは、無料の CircleCI アカウントに登録し、CircleCI MCP サーバーについてさらに詳しく学びましょう（英語）。 セットアップは数分で完了し、その瞬間から、これまでよりずっとスムーズにテストの失敗へ対処できるようになります。
導入に関するご相談やご不明点がありましたら、こちらからお気軽にお問い合わせください。
