2026年 1〜3月の新機能 ── エージェント化の加速
シリーズ構成 Ch.1 プロローグ / Ch.2 2026年1〜3月の新機能（本章） / Ch.3 コア機能詳解 / Ch.4 Cursor Rules深掘り / Ch.5 コンテキスト管理 / Ch.6 Automations・Cloud Agents・Bugbot / Ch.7 ベストプラクティス / Ch.8 アンチパターン / Ch.9 エピローグ
2026年の第 1 四半期、Cursor は約 3 ヶ月という短期間に 6 つの大型リリースを送り出した。個別に見ると「便利な機能追加」だが、並べてみると一本の筋が浮かび上がる──エージェントの自律性を段階的に引き上げ、人間が介在しなければならない場面を絞り込んでいくという設計方針だ。
timeline
title Cursor 2026 Q1 リリースタイムライン
section January 2026
エージェント高度化 : サブエージェント強化
: Extensible Skills (エディタ・CLI)
: 長時間タスクのコンテキスト保持改善
section February 2026
Feb 25 Bugbot Autofix GA : PR 自動修正エージェント
: 35%以上の修正がそのままマージ
Feb Plugin Marketplace : Design / DB / Payment / Analytics
section March 2026
Mar 4 JetBrains 対応 : ACP 経由で IntelliJ 等に対応
: 全フロンティアモデル利用可
Mar 5 Automations : 常時稼働エージェント
: GitHub / Slack / Linear / PagerDuty
Mar 19 Composer 2 : フロンティアレベルのコーディング性能
: Composer 1.5 比 3× のリミット
Mar 25 Self-hosted : 完全自社ネットワーク内でクラウドエージェント
: エンタープライズ・金融・医療向けこの章では各リリースを時系列で追いながら、それぞれが何を変えたのかを具体的に見ていく。
January 2026：エージェントの高度化
サブエージェントと Extensible Skills
1 月のアップデートは地味に見えるが、後続のリリースすべてを支える基盤になっている。
従来の Composer（Agent Mode）は、ひとつの AI セッションがタスク全体を処理していた。これは「フロントエンドの修正をしながらバックエンドの型定義も追う」「テストを書きながら CI の設定も確認する」といった、現実の開発で普通に起きる並行作業が苦手だった。
1 月のアップデートで、サブエージェントの仕組みが強化された。メインエージェントがタスクを分解し、専門化されたサブエージェントに並行して委譲できるようになった。たとえば「認証モジュールをリファクタリングして、あわせてテストカバレッジを 80% 以上にしてほしい」という指示に対し、メインエージェントが計画を立て、リファクタリング担当と テスト生成担当に分割して同時進行させる、といった動きが可能になった。
さらに注目すべきは Extensible Skills だ。エージェントが持てるスキル（ツール）を、ユーザーやチームが独自に定義・追加できる仕組みだ。エディタ内と CLI の両方で動作する。
具体的なユースケースを見てみよう。たとえば社内の API ドキュメント生成ツールがあるとする。従来は「エージェントに API を実装させてから、自分でドキュメントコマンドを実行する」という手順だった。Extensible Skills を使えば、エージェントが実装を完了した後に自律的にドキュメント生成スキルを呼び出せる。
// .cursor/skills/generate-api-docs.json
{
"name": "generate-api-docs",
"description": "社内 API ドキュメント生成ツールを実行する",
"command": "pnpm run docs:generate --output ./docs/api",
"trigger": "when_api_file_modified",
"confirmation_required": false
}このスキル定義をリポジトリに含めておけば、チーム全員のエージェントが同じスキルセットを持つ。「エージェントの振る舞いをコードで管理する」という思想は、後述する Cursor Rules とも一貫している。
長時間タスクでのコンテキスト保持改善
もうひとつの改善は、長時間タスクでのコンテキスト保持だ。
大規模リファクタリングや複数モジュールにまたがる機能追加では、エージェントのセッションが長くなるにつれて「最初の指示を忘れる」「既に変更したファイルを再度変更しようとする」問題が起きていた。1 月のアップデートでは、タスクの進行状態をチェックポイントとして内部に保持する仕組みが改善され、数十ファイルにわたる長時間タスクでの一貫性が向上している。
February 2026：Bugbot Autofix GA と Plugin Marketplace
Bugbot Autofix の進化
2 月 25 日、Bugbot Autofix が GA（一般提供開始）を迎えた。
Bugbot はもともと、PR に対して「このコードにバグがある可能性があります」とコメントするレビューアーとして動いていた。GA 版で役割が大きく変わった。レビューアーから自動修正者への転換だ。
仕組みはこうだ。
sequenceDiagram
actor Dev as 開発者
participant GH as GitHub
participant Bugbot as Bugbot サービス
participant Agent as クラウドエージェント
participant VM as テスト用 VM
participant PR as PR (GitHub)
Dev->>GH: PR をオープン
GH-->>Bugbot: PR イベント通知
Bugbot->>Agent: クラウドエージェントを自律起動
Agent->>GH: コード差分・コンテキストを取得
Agent->>VM: 修正候補コードをビルド・テスト実行
VM-->>Agent: テスト結果（Pass / Fail）
alt テスト Pass
Agent->>PR: 修正提案コメント + パッチを追加
PR-->>Dev: レビュー通知
Dev->>PR: 承認 → マージ
else テスト Fail
Agent->>Agent: 別アプローチで再試行（最大 3 回）
Agent->>PR: 「自動修正できませんでした」コメント
end開発者が PR を作った瞬間、Bugbot が静的解析・型チェック・テスト実行を経て潜在的なバグを検出する。バグを見つけた場合、クラウドエージェントがスポーン（起動）し、専用 VM 上で修正を試みる。修正したコードが既存テストを通過したら、PR に修正提案を直接プッシュする。
この GA 版で注目すべき数字がある──提案された修正の 35% 以上が、そのままマージされているという点だ。残りの 65% も「完全には正しくないが方向性は正しい」ものが多く、開発者が少し手を加えてマージするケースが多い。完全自動修正 35% という数字は一見低く見えるかもしれないが、レビューコストや修正の往復を考えると、開発速度への貢献は数字以上に大きい。
実際のシナリオで考えてみよう。あなたが機能追加の PR を作った。レビュー待ちの間に Bugbot が動き、null チェック漏れを 2 箇所・型の不一致を 1 箇所検出し、修正済みのコードを PR に追加してくれた。あなたはそれを確認してマージするだけだ。レビュアーが同じ指摘をして、あなたが修正して、再レビューを依頼して……というラウンドトリップがまるごと消える。
Plugin Marketplace のローンチ
2 月にはもうひとつ、Plugin Marketplace がローンチした。
Cursor の機能をサードパーティが拡張できるエコシステムだ。初期ラインアップは Design・DB・Payment・Analytics の 4 カテゴリに分かれている。たとえば Design カテゴリには Figma 連携プラグインが含まれており、デザインファイルを参照しながらコンポーネントを生成する、といった使い方が可能だ。DB カテゴリには Supabase・PlanetScale との連携が含まれ、スキーマ定義をコンテキストとして読み込んだ状態でクエリやマイグレーションを生成できる。
March 4：JetBrains 対応（ACP 経由）
Cursor は VS Code フォークとして始まったため、「JetBrains ユーザーは使えない」という声が多かった。3 月 4 日のアップデートで、この制約が取り除かれた。
**Agent Client Protocol（ACP）**を介して、IntelliJ IDEA・PyCharm・WebStorm・GoLand といった JetBrains IDE で Cursor のエージェント機能が使えるようになった。ACP はエージェントとエディタを疎結合にするプロトコルで、エディタ側の実装が変わっても同じエージェント機能を利用できる設計になっている。
JetBrains ユーザーにとって大きいのは、全フロンティアモデルへのアクセスが提供される点だ。OpenAI・Anthropic・Google・Cursor のすべてのフロンティアモデルを、使い慣れた JetBrains IDE から呼び出せる。
Java・Kotlin のエンタープライズ開発を JetBrains で行っているチームは多い。そうしたチームがエディタ移行のコストなしに Cursor のエージェント機能を導入できるのは、採用障壁を大幅に下げる。
March 5：Automations
常時稼働エージェントという発想
3 月 5 日リリースの Automations は、このシリーズ全体で最も重要なリリースと言っていい。
それまでのエージェントはすべて「人間がエディタを開いて指示を出す」ことで起動していた。Automations はこの前提を崩す。エージェントは常時稼働しており、指定したイベントが発生したら自律的に動く。
対応トリガーは以下のとおりだ。
| トリガー | 想定ユースケース |
|---|---|
| GitHub PR | コードレビュー補助・Bugbot との連携 |
| Slack メッセージ | #deploy-requests チャンネルへの投稿でデプロイ準備 |
| Linear issue | 新規チケット作成で実装スケルトンを生成 |
| PagerDuty アラート | インシデント発生でホットフィックス候補を作成 |
| cron | 定期的なコード品質レポート・依存関係の更新確認 |
| webhook | 任意の外部システムとの連携 |
設定は cursor.com/automations で行い、テンプレートを Marketplace から入手できる。設定の実体は YAML で記述され、バージョン管理できる。
# .cursor/automations/pr-review-assist.yaml
name: PR レビュー支援
description: PR がオープンされたら、変更箇所のテスト漏れをチェックして提案する
trigger:
type: github_pr
events: [opened, synchronize]
filters:
branches:
- main
- "release/*"
agent:
model: cursor-frontier
skills:
- analyze-test-coverage
- suggest-test-cases
context:
include:
- changed_files
- related_test_files
- cursor_rules
output:
type: pr_comment
format: markdown
require_approval: falseflowchart TD
T1["GitHub PR オープン"]
T2["Slack メッセージ"]
T3["Linear Issue 作成"]
T4["PagerDuty アラート"]
T5["cron スケジュール"]
T6["Webhook"]
Router["Automations ルーター<br/>（cursor.com/automations）"]
A1["エージェント起動<br/>PR レビュー支援"]
A2["エージェント起動<br/>デプロイ準備確認"]
A3["エージェント起動<br/>実装スケルトン生成"]
A4["エージェント起動<br/>ホットフィックス候補作成"]
A5["エージェント起動<br/>品質レポート生成"]
O1["PR コメント"]
O2["Slack 返信"]
O3["Linear チケット更新"]
O4["PR + Slack 通知"]
O5["Slack / Email レポート"]
Approval{"承認が<br/>必要か？"}
T1 --> Router
T2 --> Router
T3 --> Router
T4 --> Router
T5 --> Router
T6 --> Router
Router --> A1
Router --> A2
Router --> A3
Router --> A4
Router --> A5
A1 --> Approval
A2 --> Approval
A3 --> Approval
A4 --> Approval
A5 --> Approval
Approval -- "Yes（設定による）" --> Human["人間がレビュー・承認"]
Approval -- "No（自動実行）" --> O1
Human --> O1
Human --> O2
Human --> O3
Human --> O4
Human --> O5
A2 -.-> O2
A3 -.-> O3
A4 -.-> O4
A5 -.-> O5
style Router fill:#1e1e2e,stroke:#cba6f7,color:#cdd6f4
style Approval fill:#181825,stroke:#f38ba8,color:#cdd6f4
style Human fill:#181825,stroke:#a6e3a1,color:#cdd6f4実際の開発フローへの影響
Automations が普及すると、開発フローの「空白時間」が埋まっていく。
Before（Automations なし）：
- 機能実装 → PR 作成
- ＜レビュー待ち：数時間〜1 日＞
- レビューコメントへの対応
- 再レビュー待ち
- マージ
After（Automations あり）：
- 機能実装 → PR 作成
- Bugbot が即座に潜在バグを検出・修正提案
- Automation がテスト漏れを指摘・テストケースを追加提案
- 人間のレビュアーは「AI が指摘できないアーキテクチャ上の懸念」だけに集中
- マージ
人間のレビュアーの役割が「網羅的なチェック」から「判断が必要な部分への集中」に変わる。これは品質向上とスピード向上を同時にもたらす。
March 19：Composer 2
Composer 2 は、コーディング性能そのものを大幅に引き上げたアップデートだ。
「フロンティアレベルのコーディング性能」というのは、現時点で最高性能の大規模言語モデルと同等の能力でコード生成・編集を行えることを意味する。SWE-bench（実際のソフトウェアエンジニアリングタスクを評価するベンチマーク）での性能が Composer 1.5 から大きく向上している。
実感として違いが出るのは、曖昧な指示への対応だ。「このコードをきれいにして」「パフォーマンスを改善して」といった抽象的な指示に対し、Composer 2 は意図を推論してより的確な変更を提案する。
// Before: Composer 1.5 に「この関数を改善して」と指示した場合の出力例
// 変数名の変更やコメント追加にとどまることが多かった
async function fetchUserData(id: string) {
const response = await fetch(`/api/users/${id}`)
const data = await response.json()
return data
}
// After: Composer 2 に同じ指示をした場合の出力例
// エラーハンドリング・型安全性・再試行ロジックまで考慮した改善を提案
async function fetchUserData(id: string): Promise<User> {
const MAX_RETRIES = 3
let lastError: Error | null = null
for (let attempt = 0; attempt < MAX_RETRIES; attempt++) {
try {
const response = await fetch(`/api/users/${id}`)
if (!response.ok) {
throw new Error(`HTTP error: ${response.status} ${response.statusText}`)
}
const data = await response.json()
return UserSchema.parse(data) // Zod スキーマでバリデーション
} catch (error) {
lastError = error instanceof Error ? error : new Error(String(error))
if (attempt < MAX_RETRIES - 1) {
await new Promise(resolve => setTimeout(resolve, 1000 * (attempt + 1)))
}
}
}
throw new Error(`Failed to fetch user ${id} after ${MAX_RETRIES} attempts: ${lastError?.message}`)
}使用量の面でも改善がある。Composer 2 のリミットは Composer 1.5 の 3 倍に設定されており、大規模なタスクを途中で打ち切られる心配が減った。
March 25：Self-hosted Cloud Agents
セキュリティとエージェントの両立
3 月 25 日の Self-hosted Cloud Agents は、エンタープライズ採用の最後の障壁を取り除くリリースだ。
クラウドエージェントの課題は「コードが外部サーバーに送られる」点にあった。金融・医療・防衛といった規制産業では、このリスクが Cursor 採用の根本的な障壁になっていた。
Self-hosted Cloud Agents は、エージェントの計算基盤を完全に自社ネットワーク内に閉じることを可能にする。コードベース・ビルド出力・シークレット・ログに至るすべてが、自社のオンプレミスまたはプライベートクラウド内に留まる。
graph LR
subgraph External["Cursor クラウド（外部）"]
Coordinator["エージェント<br/>コーディネーター<br/>（指示のみ送信）"]
end
subgraph Internal["自社ネットワーク（内部）"]
Runner["Self-hosted<br/>Agent Runner"]
Code["コードベース"]
Build["ビルド・テスト環境"]
Secrets["シークレット管理<br/>（Vault 等）"]
Logs["実行ログ"]
end
Dev["開発者<br/>（Cursor エディタ）"] --> Coordinator
Coordinator -- "タスク指示<br/>（コード非含有）" --> Runner
Runner --> Code
Runner --> Build
Runner --> Secrets
Runner --> Logs
Runner -- "実行結果サマリー" --> Coordinator
Coordinator --> Dev
style External fill:#2a1a1a,stroke:#f38ba8,color:#cdd6f4
style Internal fill:#1a2a1a,stroke:#a6e3a1,color:#cdd6f4外部の Cursor クラウドには「タスクの指示内容」だけが渡る。コードの内容・シークレット・ビルドアーティファクトは外部に出ない。エージェントの計算そのものは自社内のランナーで行われる。
設定は Kubernetes ベースのランナーを自社環境にデプロイする形で行う。既存のセキュリティポリシーや VPN・ファイアウォール設定を維持したまま導入できる設計になっている。
まとめ：3 ヶ月で何が変わったか
2026年第 1 四半期の 6 つのリリースを振り返ると、一本の設計思想が見える。
まずエージェントの能力を引き上げた（Extensible Skills・サブエージェント強化）。次にエージェントが常時稼働できるようにした（Automations）。そして人間の介在が難しかった「PR の修正」を自律的に処理できるようにした（Bugbot Autofix GA）。コーディング性能そのものを上げた（Composer 2）。使用できるエディタの選択肢を広げた（JetBrains 対応）。そしてセキュリティ要件の高い環境でも動かせるようにした（Self-hosted Cloud Agents）。
これらは点ではなく、線だ。エンジニアがコードを書く時間を減らし、エージェントを管理する時間を増やす──その方向に、Cursor は着実に進んでいる。
次章では、これらの基盤となるコア機能（Tab・Composer・Chat・Plan Mode）を詳しく掘り下げる。
本シリーズは 2026年 3 月 30 日時点の情報を元に執筆しています。