*この記事は、Cursor Advent Calendar 2025の記事です。

開発チームにとって、開発フローやツールのコスト最適化は定期的に見直しや取り組みが必要なタスクの１つです。プロダクト・事業者目線においても、開発フローの中で発生するコストを最適化することは、商品原価の削減にもつながります。見直しによるパイプラインの実行速度の改善などが実現すれば、開発生産性やユーザーからの機能要望への対応速度改善にもつながります。

今回はCI / CDパイプラインの状況をレビューし、改善を行う作業を Cursor のエージェントに任せる方法を試してみました。CircleCIなどのMCPサーバーをエージェントに接続することで、どのジョブ・ステップを調査すべきかや、現在の状況をざっくり把握することなどが効率化できます。

CircleCI MCPサーバーとは

CircleCI MCPサーバーは、Model Context Protocol (MCP) に対応したサーバーで、CircleCI のパイプライン情報やジョブの実行状況を AIエージェントが直接取得できるようにするツールです。Cursor などの MCP対応エディタと連携することで、AI が CircleCI の API を呼び出し、現状分析から改善提案、さらには設定ファイルの修正までを作業させることができるようになります。

内部的にはCircleCIの API を利用しています。そのためダッシュボードで状況をチェックしたり、APIを利用した分析基盤などを作ることも可能です。ですが、ダッシュボードのために新しくウィンドウを開き、必要な情報を目視で探す手間や、分析基盤の構築・運用コストを考えると、手軽な分析・調査手法として MCP サーバーを活用する方が向いているケースも少なくありません。

なお、CursorでのCircleCI MCPサーバーを利用する方法については、「AIコーディングエディタと CircleCI MCPを利用して、実装からCIまでを自動化する」という記事にて紹介していますので、こちらをご覧ください。

CircleCI MCPサーバーを利用して２種類の最適化を試してみる

ここではCircleCI MCPサーバー持つ機能（Tool）を使った調査や最適化について試してみました。

1: ジョブごとのリソースクラスを最適化してコスト削減

CircleCIはパイプライン内で実行されるジョブの実行時間と利用したリソースの種類やスペックに基づいてクレジットが消費されます。→ CircleCI の料金体系をざっくり理解する

そのため、もしジョブに割り当てているリソースクラスがオーバースペックであれば、不要な出費が発生していることになります。反対に実行速度が遅かったりCPUやRAMの利用率が高すぎる場合には、リソースクラスを引き上げることで実行時間を短縮することができます。

このようなリソースクラスの調査をCircleCI MCPサーバーを使って実施してみました。

Cursorに調査を依頼する

「circleci mcp を使ってジョブの実行状況を調べて、特にジョブごとの resource_class が適切かを調べてほしい」と指示を出しました。Planモードを指定することで、調査後にいきなり設定変更作業をさせるのではなく、事前に「調査結果に基づいて以下の作業をしたい」と計画を説明させることができます。

CircleCI MCPサーバはCursorが提供するプロジェクトディレクトリ名や.circleci/config.ymlの情報からプロジェクト情報などを取得します。時々CircleCI の Organization ID が必要になることがあります。この場合は、CircleCI のダッシュボードから Organization Settings を開き、Overview 画面に表示される Organization ID を取得してチャットに提供しましょう。

調査に必要な情報が集まると、Usage API を呼び出し、ジョブごとの実行データを分析します。

調査が終わると、レポート結果が報告されます。今回のケースでは、ビルドジョブにオーバースペックなリソースが設定されていることが判明しました。シンプルな1分未満で完了するビルドジョブに対して、4CPU / 8GB RAMのマシンが割り当てられています。Largeでは1分あたり20クレジットが消費されますが、提案されているSmallであれば5クレジットとジョブあたりのコストが1/4になります。

念の為CircleCIのテストインサイトもチェックしてみました。CPU Usageを目視でチェックしましたが、10%も利用されておらず、オーバースペックなのは明白です。

Agentモードを利用している場合やPlanを承認した場合は、config.ymlを更新してリソースクラスの最適化もCursorが実施してくれます。

変更後のパイプラインとジョブを念の為目視でチェックしてみました。LargeからSmallへサイズダウンしていますが、それでもまだCPU利用率は50%未満です。これであればサイズダウンによる遅延などが起きることも少なそうです。

CircleCI MCPサーバーまたはUsage APIを利用できるスクリプトなどをエージェントに付与しておくことで、このようなコスト・リソースの最適化調査をAIに任せることが可能です。AWSのAgentCoreやDevin・Kiro autonomous agent などを使えば、「エージェントが毎月調査してSlackにレポートしてくれる / BacklogやJIRAにリソース改善提案チケットが起票される」ような運用も可能になるかもしれません。

2: テストカバレッジなどの調査

CIでの改善といえば、テストのカバレッジ状況調査も重要です。100%でなければならないというわけでもありませんが、それでもテストされていない関数やファイルがどこにどれだけあるかを把握することは、不具合調査や今後の改善計画にも欠かせない情報です。

こちらについても、CircleCIのパイプライン状況をもとに調査させることができます。手元でカバレッジ調査のコマンドを実行することもできますが、CircleCIのジョブを調査させる方がセットアップやコードの同期といった準備やマシンのCPUリソースなどの効率化が期待できます。

場合によっては、そもそもカバレッジを計測していない場合もあります。このようなケースでもCursorがどのように改善すれば良いかを提案してくれます。今回のケースではVitestを利用して調査・レポートする改善提案がPlanモードで作られました。

あとは変更をcommitしてpushします。この時、Cursor RulesでCIの実行結果をチェックさせる指示を追加しておくと、改善の効果計測などを指示する手間が省けます。

調査がうまくいかない場合

CircleCI MCPサーバーを利用する際、時々ツールの利用がうまくいかないことがあります。特にリソースクラスの分析を行う際は、Cursorが想像するデータとCircleCI Usage APIが期待するデータに差異が発生することがある様子でした。

「Date cannot be in the future」のような期間や年月日に関するエラーが表示されている場合は、Cursorに「年月日のデータをYYYY-MM-DD形式で渡すように」のような指示やRuleを設定しましょう。これによって問題の発生率が低下します。

また、「Start cannot be more than 1 year ago」というエラーが起きることもあります。これはAIエージェントが「今日の年月日」をモデルの知識カットオフ日と誤認した場合に発生します。CircleCIのUsage API は過去1年以内のデータのみ取得可能なため、モデルのカットオフ・リリース日ベースで調査指示を出すと、CircleCIが想定するよりも広い範囲のデータを要求してしまうことがあります。もしこの問題が起きた場合は、現在の年月日を伝えることと、調査範囲を1年以内にすることで解決します。

まとめと次のステップ

CircleCI MCPサーバーと Cursor AI の組み合わせにより、CI/CD パイプラインの改善を AIエージェントに任せれます。現状分析から改善提案だけを任せて、対応するかどうかの判断は開発チームで行うこともできます。また、実装や検証まで、一連のフローまで任せてしまうことで、開発に専念できるようにするという考え方も一つでしょう。

今回はCursorに指示を出す形にしました。継続的な改善を目指すのであれば、このような構成やフローを自動化できるエージェント・エージェンティックワークフローを検討しても良さそうです。特にCircleCIについては、MCPサーバーで分析が可能ですので、MCPに対応したエージェントであれば比較的少ない工数でPoCを始めることができます。

AIエージェントと MCPサーバーの組み合わせは、CI/CD 改善だけでなく、さまざまな開発業務の効率化に応用できます。今回の経験が、皆さんのプロジェクトでの AI活用の参考になれば幸いです。