開発チームにとって、CI/CDパイプラインのコスト最適化は定期的に見直しが必要なタスクです。CircleCIではクレジットという単位で利用料金が計算されますが、ジョブに割り当てたリソースが実際の処理に対してオーバースペックであれば、その分だけ無駄なコストが発生します。
とはいえ、すべてのジョブのリソース使用状況を手動で確認し、最適なリソースクラスを選定する作業は手間がかかります。本記事では、Cursor等のAIエージェントとCircleCI MCPサーバーを連携させ、この分析作業を効率化する方法を紹介します。
CircleCI MCPサーバーとは
CircleCI MCPサーバーは、Model Context Protocol（MCP）に対応したOSSのツールです。MCPはLLMと外部システム間のコンテキスト管理を標準化するプロトコルであり、CircleCI MCPサーバーを利用することで、Cursor、Claude Code、VS Code、Windsurf等のMCP対応ツールからCircleCIのAPIへ自然言語でアクセスできるようになります。
CircleCI MCPサーバーが提供する主要な機能は3つあります。1つ目はビルド診断機能で、失敗したビルドのログ取得やエラー原因の特定を支援します。2つ目はテスト分析機能で、フレーキーテストの検出やテスト結果の詳細確認が可能です。3つ目がリソース分析機能で、Usage APIを通じてジョブごとのCPU・RAM使用率を取得し、リソースクラスの最適化候補を特定できます。
本記事ではこの3つ目のリソース分析機能を活用し、コスト最適化を実践します。
CircleCIのリソースクラスを最適化してコストを削減する
CircleCIの料金はジョブの実行時間とリソースクラスによって決まります。リソースクラスはジョブに割り当てるCPUとRAMのサイズを指定するもので、サイズが大きいほど1分あたりのクレジット消費が増加します。たとえば(x86) Dockerの場合smallは5クレジット/分、mediumは10クレジット/分でlargeは20クレジット/分を消費します。
1分あたりの単価が大きく変わるため、ジョブごとに最適なリソースクラスを割り当てることができているかを把握し、調整を行うことで月々のコストを最適化できます。
ここからは「ジョブで必要なスペックよりも過剰なリソースを割り当てているものがないか」の探索を、CircleCI MCPと連携したAIエージェントに任せてみましょう。
Cursorへの調査依頼
CircleCI MCPサーバーの設定方法については、ドキュメントをご確認ください。
https://github.com/CircleCI-Public/mcp-server-circleci?tab=readme-ov-file#installation
CursorにCircleCI MCPサーバーを設定した状態で、以下のようなプロンプトを送信します。
circleci mcp を使ってジョブの実行状況を調べてください。
特にジョブごとの resource_class が適切かを調べてほしいです。
年月日のデータは、YYYY-MM-DD形式で渡すようにしてください。
Cursorは.circleci/config.ymlやGitリモートの情報からプロジェクトを特定し、Usage APIを呼び出してジョブごとの実行データを分析します。
もしCursorなどのAIエージェントが「Organization IDが必要」とコメントしてきた場合は、CircleCIダッシュボードの Organization Settings > Overview から取得してチャットに提供してください。
CircleCI MCPサーバーがエラーを返す場合
MCPサーバーのバージョンによっては、一定確率でAIエージェントがデータ取得に失敗することがあります。これはデータを取得する際に送信する年月日のデータ周りにて発生したエラーによるものが多いです。
もし「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年以内にすることで解決します。
分析結果の読み方
MCPサーバーを利用してエージェントは CircleCI からデータを取得します。エージェントは取得したデータを分析して、CPU使用率やRAM使用率の低いジョブの特定を試みます。分析が終わると、チャット欄にエージェントによるレポートが出力されます。
分析結果には、対象ジョブの名前、現在のリソースクラス、平均CPU使用率、平均RAM使用率、そして推奨されるリソースクラスが含まれます。
分析の結果、過剰なリソースクラスを設定しているジョブが見つかった場合は、推奨サイズの提案などをレポートしてくれます。
たとえば、1分未満で完了するシンプルなビルドジョブにlarge（4CPU / 8GB RAM）が割り当てられており、CPU使用率が10%未満だったとします。この場合、small（1CPU / 2GB RAM）へ変更すれば、ジョブあたりのクレジット消費を75%削減できます。
CircleCI ダッシュボードでレポートを検証する
生成AIによる調査や分析は非常に便利です。しかしその非決定性から、エージェントが実施した調査結果や提案が本当に適切かを検証してからアクションに移行することをお勧めします。今回のようなCircleCIの利用状況分析については、CircleCIのダッシュボードからジョブごとのレポートを確認しましょう。
CircleCIダッシュボードからジョブの詳細画面を開いて、Resourcesタブを選択します。このタブでは、ジョブごとのCPU およびRAM の利用状況がグラフで表示されます。
もしこのグラフでCPUの利用率が50-70%よりも低い値を常に示している場合は、提案通りにリソースクラスをダウンサイズすることで、コスト削減が期待できます。
config.ymlの変更
分析結果に基づいてリソースクラスを変更する場合、Cursorに変更を依頼できます。Agentモードを使用している場合は、Cursorが.circleci/config.ymlを直接編集してプルリクエストを作成することも可能です。
画像の例では、以下のようにリソースクラスをlargeからsmallに変更しています。
jobs:
build:
docker:
- image: cimg/node:24.0
resource_class: small # largeから変更
steps:
- checkout
- run: npm ci
- run: npm run build
変更後は必ずパイプラインを実行し、ジョブが正常に完了することを確認してください。
また、リソースクラス変更後も同様にダッシュボードでリソースの状況をチェックしましょう。変更後のリソースクラスで実行されたジョブのCPU使用率が、常に80%を超えるような状況になっていないかを確認します。
もし使用率が高すぎる場合は、実行時間の増加につながることがあります。実行時間が増加してしまうと、単価を下げたことによるコスト削減効果を相殺してしまう可能性があります。
まとめ
CircleCI MCPサーバーとAIエージェントを組み合わせることで、CI/CDパイプラインのコスト最適化作業を効率化できます。Usage APIを通じたリソース使用状況の分析、最適化候補の特定、config.ymlの修正提案まで、一連の作業をAIエージェントに任せられます。
今回はCursorに指示を出す対話形式で実施しましたが、AWS Bedrock AgentCore等のエージェンティックワークフローを構築すれば、月次で自動的にレポートを生成しSlackに通知する、といった運用も実現できます。MCPに対応したエージェントであれば、比較的少ない工数でPoCを始められます。
AWSとCircleCIの組み合わせについては、AWSのブログ（英語）でstep by stepのガイドも公開されていますので、ぜひご一緒にご覧ください。
分析のみをAIに任せ、実際のリソースクラス変更は開発チームで判断するアプローチも有効です。特に本番環境に影響するパイプラインについては、変更前にステージング環境でテストすることを推奨します。
AIエージェントとMCPサーバーの組み合わせは、CI/CD改善だけでなく様々な開発業務の効率化に応用できます。CircleCI MCPサーバーの詳細は公式ドキュメントおよびGitHubリポジトリを参照してください。