Cursor / Devin / Claude Code / Kiro など、さまざまなAIコーディングツールが2025年に登場・成長してきました。しかしその一方で生成AIが生み出した「在庫」をどのように処理するのかが、次の開発生産性における課題となりつつあります。

この記事では、CircleCIとCursorを例に、AIコーディングツールが自身でPull Request前のコード品質をチェック・改善できる仕組みについて紹介します。

コードにおける「在庫」とは

t-wadaさんのセッションにおいて、「レビュー待ちのPull Requestは、在庫である」と説明されています。

まだプロダクション環境、つまり顧客の目につくところに作られたものが提供されていない状態。いわば製造された商品が倉庫に在庫として積み上げられている状態が、マージされずにレビュー待ち状態で Hold されているPull Requestのことを「在庫」と呼ぶと言えるでしょう。

作られたものが「在庫」でありリリースされていない以上、どれだけAIエージェントがコードを生成してもビジネス的・プロダクト的な前進はまだ何も起きていない状態であるともいえます。

なぜ倉庫に放置されるのか？

端的に表現すると、「作られたものを、顧客に提供して良いかの判断ができない」ことが2025年におけるAIコーディングが抱える課題といえます。実際、2025/12に開催されたAWS re:invent 2025において、AmazonのCTOであるDr. Werner VogelsはAIコーディング、特に Vibe Codingについて次のように述べています。

「Vibe coding is fine, but only if you pay close attention to what is being built. We can’t just pull a lever on your IDE and hope that something good comes out. That’s not software engineering. That’s gambling.」（vibe codingは大丈夫だが、構築されるものに細心の注意を払う場合に限る。IDEのレバーを引いて何か良いものができることを期待するのはソフトウェアエンジニアリングじゃない。それはギャンブルだ。）

https://youtu.be/3Y1G9najGiI?si=RApyNm3tfXI7zBJz&t=3369

結局のところ、自社の開発チームであろうがパートナーや委託先であろうが生成AIであろうが、「作られたコードが良いものであるかどうか」を誰かが判断せざるをえず、その仕組みがあるかどうかによって生成されたコードが在庫として倉庫に積み上げられるのか、それとも迅速に顧客へ提供されるのかの分かれ目になっています。

実際、CircleCIやDORAのリサーチによると、「AI ツールの採用が進んでいるにもかかわらず、2024年のデリバリースループット（顧客に届く新しいコードの量）は停滞、あるいは減少傾向にある」とも言われいます。これらのことを踏まえると、AIコーディングツールは「開発フェーズを加速させたが、ソフトウェア開発サイクル（SDLC）で見ると、新しいボトルネックを顕在化させている」といえるでしょう。

CIを活用して、「AIがコードを評価・改善する」

この問題を解決するには、新しく生まれたボトルネック、つまり生成されたコードの品質チェックについても自動化する必要があります。おそらくこの問題については、「スイスチーズモデル」的な解決を目指すことになると考えています。１つの何かで問題を解決させるのではなくいくつかの防壁によって複数あるいは大きな穴を塞いでいく、いわゆる冗長化によるリスク対策です。

この「スイスチーズ」には、様々な手法が提案されることでしょう。人間によるコードレビューはもちろんのこと、Code RabbitなどのAIコードレビューや自動化テスト、プレビューデプロイによる動作確認なども含まれます。

今回はその中の１つとして、「AIコーディングツールとCIサービスを連動させ、AIが自分でビルドやテストの問題を解決する仕組み」についてCircleCIとCursorを例に紹介します。

MCPによってコーディングエージェントとCIを連結する

AI コーディングアシスタントを使ったコーディングが当たり前になった今、開発のスピードは劇的に向上しています。しかし、コードを書いた後の CI/CD パイプライン確認作業は、依然として手動で行う必要がありました。git push を実行した後、ブラウザで CircleCI のダッシュボードを開き、パイプラインの実行状況を確認する。失敗した場合はログを読み解く。この一連の作業は、コンテキストスイッチを伴う非効率なプロセスです。

CircleCI MCP Server は、この課題を解決します。Model Context Protocol(MCP)を通じて AI アシスタントと CI/CD システムを直接接続することで、自然言語でパイプラインの状態を確認できます。MCPサーバーを接続したコーディングエージェントに指示を出すことで、「git push後にCIがfailしたかどうかの検知」や「発生した問題の確認と調査、修正」までをエージェントに任せることができます。

CircleCI MCPサーバーをCursorに接続する

CircleCI MCP Serverを利用するには、CircleCI で API トークンを取得する必要があります。CircleCI は、Personal API Token と Project API Token の 2 種類のトークンを提供しています。どちらでもMCPサーバーは動作しますが、漏洩リスクなどを考えると、プロジェクトごとにmcp.jsonを作成し、CircleCIのProject API Tokenをプロジェクトごとに発行して設定するほうがより安全に運用できます。

なお、トークンの取得方法は、CircleCI の公式ドキュメントに詳しく記載されています。

取得した API トークンは、.env ファイルに記述します。プロジェクトのルートディレクトリに .env ファイルを作成し、以下の形式でトークンを記述してください。

CIRCLECI_TOKEN=CCIPAT_ で始まるトークン文字列

この .env ファイルは、必ず .gitignore に追加し、Git リポジトリにコミットしないようにしてください。

次に、Cursor の MCP 設定を JSON 形式で記述します。プロジェクト単位で管理する場合、.cursor/mcp.json ファイルに設定を記述しましょう。

{
  "mcpServers": {
    "circleci-mcp-server": {
      "command": "npx",
      "args": ["-y", "@circleci/mcp-server-circleci"],
      "envFile": "${workspaceFolder}/.env"
    }
  }
}
   

envFile を利用することで、mcp.json ファイル自体には API トークンを直接記述する必要がなくなります。これにより、mcp.json を Git で管理できるようになります。Gitで管理することで、チーム全体で同じ設定を共有しながら、各開発者が自分の .env ファイルに個別のトークンを設定することが可能となります。

mcp.json ファイルを作成したら、Cursor の設定画面で CircleCI MCP Server を有効化します。Cursor の設定メニューから、Tools & MCP セクションを開きましょう。

Installed MCP Servers の一覧に circleci-mcp-server が表示されます。このサーバーの横にあるトグルスイッチをオンにしましょう。これでセットアップは完了です。

AIにCIパイプラインまでチェックさせてみよう

セットアップが完了したら、実際に Cursor の AI チャットを通じて CircleCI を操作してみましょう。

最もシンプルな使い方は、現在のプロジェクトの最新パイプライン状態を確認することです。AI チャットに「circleci の最近実行したジョブについて分析して」と入力すると、MCP サーバーが自動的に Git のリモート情報とアクティブなブランチを読み取り、対応する CircleCI プロジェクトとパイプラインを特定します。

パイプラインの取得に成功すると、AI アシスタントはテスト結果の詳細な分析を提供します。成功したテストについては、ファイル名、実行時間、テスト内容が報告されます。

さらに、AI アシスタントは追加のテストを提案することもあります。特にエッジケースのテストやバリエーションの追加などは、生成AIが得意とする分野の１つでもありますので、テストの改善にも役立てることができます。

失敗時のリカバリーも

パイプラインが失敗した場合、AI アシスタントは get_build_failure_logs ツールを使用して、失敗したジョブの詳細なログを取得します。ログには、各ステップの実行結果、エラーメッセージ、終了コードが含まれています。AI がこれらの情報を分析して、問題の原因についても報告してくれます。

例えば、環境変数が不足している場合、AI は「db:setup ステップで環境変数が見つかりません」といった形で問題を特定します。config.yml ファイルへの環境変数追加や CircleCI プロジェクト設定での環境変数設定といった、具体的な修正方法も提案されるでしょう。

AIにCIパイプラインのチェックを強制する

これらの作業を毎回チャットからAIに伝えるのは煩雑です。幸いなことにCursor / Claude Codeなどのコーディングエージェントには、「ルール」や「フック」などAIに作業を指示するドキュメントを作らせることができます。

Cursorの場合、.cursor/rules/ci.mdcを作成し、以下のようなドキュメントを作ってみましょう。

---
description: git push実行後にCircleCIパイプラインの成功を確認するルール。CircleCI、CI/CD、パイプライン、git pushに関連する作業時に適用される。
alwaysApply: false
---

# CircleCI パイプライン確認ルール

git pushを実行した後は、必ず以下の手順を実行すること：

1. CircleCI MCPツール（`get_latest_pipeline_status`）を利用して、最新のパイプラインの状態を確認すること
2. パイプラインのステータスが「success」であることを確認すること
3. パイプラインが「running」状態の場合は、30-60秒のsleepを実行してから再度ステータスを確認すること（最大5回まで再試行すること）
4. パイプラインが「failed」状態の場合は、以下の手順を実行すること：
   - `get_build_failure_logs`ツールを使用して失敗ログを取得すること
   - 失敗の原因を分析すること
   - 原因に基づいて修正を実施すること
   - 修正後、再度git pushを実行し、パイプラインが成功するまで確認を継続すること

## 実装の詳細

- CircleCI MCPツールを使用する際は、`projectSlug`と`branch`パラメータを使用すること
- `projectSlug`は`listFollowedProjects`ツールで取得するか、`workspaceRoot`、`gitRemoteURL`、`branch`を組み合わせて使用すること
- パイプラインの確認は、git push実行後すぐに開始すること
- パイプラインが完了するまで（successまたはfailedになるまで）確認を継続すること

---で囲まれた範囲にルールの説明や実行条件などを記載します。そしてその後、「コーディングエージェントが何をすべきか」を説明しましょう。この例の場合、コーディングエージェントがgit pushを実行した場合にルールがトリガーされます。よってgit pushまでをエージェントに指示させることで、CIパイプラインが成功したかどうかや失敗した原因の修正などを自動化させることができます。

コーディングエージェント x CIパイプラインの可能性

最終的にはやはり人間のコードレビューが必須となりますが、それでもこのような形で作業時のコンテキストスイッチを削減し、CIパイプラインによる「わかりきったコードや機能の問題」をレビュー前にフィルタすることができます。このような品質に関する防壁をスイスチーズモデルのように展開することで、いわゆる「不良在庫」が倉庫に入らない状態、品質に問題のあるコードを含むPull Requestが「レビュー待ち」の待機列に並ばない環境が作れます。

完璧な解決策である銀の弾丸、正直これがあるなら今すぐにでも飛びつきたいなと思います。ですがAIコーディングが開発者の仕事を完全に奪わないということが判明したように、これからもSDLC / AI-DLCのライフサイクルに発生し続けるボトルネックを解消する仕事はなくならないでしょう。

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

関連ドキュメントなど

• https://github.com/CircleCI-Public/mcp-server-circleci
• https://github.com/CircleCI-Public/circleci-mcp-cookbook
• https://hidetaka.dev/ja/writing/dev-notes/secure-api-key-management-on-mcp-server-in-cursor