AIコーディング支援と聞くと、多くのIT技術者はClaude Code、Codex、GitHub Copilot、Cursorなどを思い浮かべるはずです。
その中でCursorが公開したComposer 2.5は、単に「また新しいコーディングモデルが出た」という話ではありません。
ポイントは、汎用AIをIDEに組み込んだだけではなく、Cursorという開発環境の中で動くことを前提に鍛えたモデルだという点です。
つまり、これは「頭のいいAI」単体の話ではありません。
開発ツールとAIモデルを一体で最適化すると、実務のコーディング支援はどう変わるのか。
Composer 2.5は、その問いに対するCursorの現時点での答えです。
Composer 2.5で見るべきなのは、モデル単体の性能ではない
Cursorの公式ブログによると、Composer 2.5は2026年5月18日に公開され、Cursor内で利用できるモデルとして提供されています。
Cursorは、Composer 2.5について、Composer 2よりも長時間の作業、複雑な指示への追従、協働時の振る舞いが改善されたと説明しています。
また、Composer 2.5はComposer 2と同じく、Moonshot AIのKimi K2.5をベースにしています。Kimi K2.5自体は、コーディング、推論、エージェント的なタスクを重視したオープンなモデルとして公開されています。
ここだけ見ると、「高性能で安いコーディングモデル」という印象になります。
しかし、IT技術者が見るべき本質はそこではありません。
重要なのは、Composer 2.5がCursorの中で働くAIとして鍛えられていることです。
AIはコード補完から、開発タスクを進めるエージェントへ移っている
従来のAIコーディング支援は、開発者が質問し、AIがコード片や説明を返す使い方が中心でした。
しかし最近のエージェント型開発では、AIは次のような動きをします。
- リポジトリ全体を読む
- 関連ファイルを探す
- 既存設計を理解する
- 変更箇所を特定する
- コードを書き換える
- テストを実行する
- エラーを見て再修正する
- 不要になったコードや設定を整理する
つまり、AIは単なる「コード補完」ではなく、小さな開発タスクを一連の作業として進めるアシスタントになってきています。
Composer 2.5は、この動きに合わせて作られています。
CursorはComposer 2の技術報告で、実際のCursor環境をできるだけ再現した形で強化学習を行い、開発者がCursorに頼む作業分布に近い問題を使っていると説明しています。Composer 2.5ではさらに、より難しいタスク、複雑なRL環境、新しい学習方法によって改善したとされています。
これは、汎用モデルをIDEに載せるだけの発想とは少し違います。
IDE、CLI、ファイル探索、ツール呼び出し、テスト実行、差分管理まで含めて、開発体験全体をモデル側に学習させようとしているわけです。
対象RLの発想が、実務の失敗に近い
Composer 2.5の学習で興味深いのは、単に「正解コード」を学ばせているだけではない点です。
CursorはComposer 2.5で、targeted RL with textual feedbackという方法を使ったと説明しています。
通常の強化学習では、長い作業の最後に報酬が与えられます。しかし、エージェントの作業は何百、何千、場合によってはそれ以上のトークンにまたがります。最後に「成功」「失敗」と言われても、モデルにとっては、どの判断が良かったのか、どのツール呼び出しが悪かったのかが分かりにくい。
そこでCursorは、モデルが間違ったツール呼び出しや望ましくない振る舞いをした箇所に、局所的なテキストフィードバックを挿入して学習させています。
たとえば、モデルが存在しないツールを呼んだ場合、単に失敗扱いにするのではなく、「利用可能なツールはこれだ」といったヒントを、その場面の文脈に与える。
これは、人間の新人エンジニアに対する指導に近いです。
単に「ダメ」と言うのではなく、次のように教える。
- この場面では別のツールを使う
- ファイルを編集する前に依存関係を見る
- テスト失敗の原因を先に読む
- 変更範囲を広げすぎない
- 説明を長くしすぎず、必要な確認を先にする
実務でAIエージェントに求めたいのは、まさにこうした振る舞いです。
コードを生成できるだけでは足りません。
開発環境の中で、どの順番で調べ、どこまで編集し、どのタイミングで確認するかが重要になります。
合成タスクを増やしているのも、実務寄りの方向である
Cursorは、Composer 2.5をComposer 2より25倍多い合成タスクで学習したと説明しています。
ここでいう合成タスクは、単なるアルゴリズム問題ではありません。実際のコードベースに根ざしたタスクです。
公式ブログでは、feature deletionの例が紹介されています。ある機能を削除したコードベースを用意し、テストを報酬として、その機能を再実装させるようなタスクです。
これは、実務にかなり近い訓練です。
現場で「機能を消す」「機能を戻す」「仕様変更に合わせて周辺を直す」という作業は、単に1ファイルを編集すれば終わるものではありません。
- UIから導線を消す
- APIやルーティングを整理する
- 不要になったコンポーネントを削除する
- テストを修正する
- ドキュメントや設定を見直す
- 残骸となったコードを消す
- アプリが壊れていないことを確認する
実務では、新規コードをきれいに生成する能力よりも、既存コードを壊さず変更できる能力の方が重要な場面が多いです。
Composer 2.5がこの方向に寄せているのは、かなり現場的です。
ベンチマークよりも、速度とコストが効いてくる
Composer 2.5は、Cursorの公開情報ではベンチマーク上でも改善が示されています。
ただし、この記事で強調したいのは、単純なスコア競争ではありません。
AIコーディングエージェントでは、1回あたりの最高性能だけでなく、速度とコストが実用性を左右します。
Cursorの公式ブログでは、Composer 2.5の価格は通常版が100万入力トークンあたり0.50ドル、100万出力トークンあたり2.50ドルとされています。さらに、同じ知能を保った高速版が100万入力トークンあたり3.00ドル、100万出力トークンあたり15.00ドルで提供されています。
この価格設計は重要です。
AIコーディング支援は、たまに使う高級ツールではなく、日常的に何度も使うものになっていくからです。
- 小さな修正
- テスト追加
- リファクタリング前の調査
- ドキュメント更新
- PR前の確認
- 既存仕様の読み解き
こうした作業に毎日使うなら、1タスクあたりの待ち時間とコストは無視できません。
Composer 2.5の価値は「Claudeより安い」ことだけではなく、日常的な開発作業に回しやすい価格帯で、エージェント的な作業を狙っている点にあります。
CursorBenchで見ているものは、実務に近い
CursorはComposer 2の技術報告で、CursorBenchという評価について説明しています。
一般的な公開ベンチマークは、問題が過剰に整理されていたり、解答が狭かったり、対象コードベースが小さかったりします。実務の開発タスクとは違うことが多い。
一方、CursorBenchはCursorのエンジニアリングチームの実際のコーディングセッションから作られた評価で、短く曖昧なプロンプトや、複数ファイルにまたがる変更を含むと説明されています。
これはかなり重要です。
開発者は、毎回きれいなプロンプトを書いてAIに依頼するわけではありません。
実際には、次のような頼み方をします。
- このバグ直して
- この機能消して
- ここの挙動がおかしい
- テスト通るようにして
- このPRの指摘に対応して
AI側は、その短い指示からコードベースを読み、意図を推測し、必要な変更を組み立てる必要があります。
Composer 2.5の文脈でCursorBenchが重要なのは、モデルを実際のCursor利用に近い状況へ寄せようとしているからです。
使いたくなる理由は、安さよりも「面倒な作業に強そう」なこと
Composer 2.5を試す価値があるのは、単に価格が低いからではありません。
むしろ注目すべきは、次のような実務タスクに向いていそうな点です。
既存コードの調査
大きなリポジトリで、仕様や実装箇所を探す作業は時間がかかります。
たとえば、次のような依頼です。
- この画面の保存処理はどこか
- このエラーメッセージはどこで出ているか
- このAPIを呼んでいる箇所を調べてほしい
- この設定値がどこで使われているか知りたい
こうした作業をAIに任せられると、開発者は設計判断に時間を使いやすくなります。
小さな修正の自動化
一つひとつは難しくなくても、積み重なると負担になる作業があります。
- 型エラーの修正
- テスト追加
- 例外処理の補強
- 古い関数名の置き換え
- 不要コードの削除
- lint対応
- ドキュメント更新
Composer 2.5のようなエージェント型モデルは、この領域で特に効果が出やすいはずです。
リファクタリング前の下調べ
リファクタリングで怖いのは、変更そのものよりも影響範囲の見落としです。
いきなりコードを書かせるより、まず次のように使う方が安全です。
- このクラスを分割したい。影響範囲を調べて
- この関数を廃止する場合、どこを直す必要があるか洗い出して
- 変更方針を出して。まだ実装はしないで
- テスト方針を先に説明して
AIに実装させる前に、調査と計画を出させる。
これだけでも十分に価値があります。
PR前のセルフレビュー
AIにレビューさせる使い方も現実的です。
- この差分で副作用がありそうな箇所を見て
- テストが足りない観点を挙げて
- 命名や責務分離の観点で違和感を指摘して
- 仕様と実装がずれていそうな箇所を探して
この使い方なら、AIが完璧でなくても価値があります。
人間のレビューに出す前に、明らかな粗を減らせるからです。
そのまま信用してよいわけではない
もちろん、Composer 2.5を含むAIコーディングエージェントを、そのまま信用するのは危険です。
特に注意すべきなのは次の点です。
「通ったように見える修正」をすることがある
テストが一部通っても、本質的に正しいとは限りません。
既存仕様を誤解したまま、表面的にエラーだけ消すことがあります。
変更範囲が広がりすぎることがある
エージェント型AIは、よかれと思って周辺コードまで修正することがあります。
小さな変更を頼んだつもりが、設計に関わる変更まで入る場合があります。
セキュリティ・権限・データ取り扱いは別問題
コードベースや社内情報をAI環境に渡す場合、モデル性能とは別に、契約、データ保持、監査、権限管理の確認が必要です。
企業利用では、「便利そうだから使う」ではなく、次を決める必要があります。
- どのリポジトリで使うか
- どの権限を与えるか
- どのデータを扱わせるか
- AI利用ログをどう残すか
- 生成コードの責任を誰が持つか
- レビューと承認をどこで挟むか
AIエージェントの性能が上がるほど、ガバナンスは後回しにできなくなります。
最初は「調査」と「小修正」から使うのがよい
Cursorを使っているIT技術者がComposer 2.5を試すなら、最初から重要な実装を丸投げしない方がよいです。
まずは、コード調査から始めるのが安全です。
- この機能に関係するファイルを洗い出して
- このエラーが発生しそうな経路を説明して
- このAPIの呼び出し元を整理して
次に、小さな修正を任せます。
- このテストを追加して
- この型エラーだけ直して
- この関数の命名を既存ルールに合わせて
この段階では、必ず差分を確認します。
慣れてきたら、いきなり実装させるのではなく、計画を出させます。
- 修正方針を出して。まだ編集しないで
- 変更対象ファイルを提案して
- テスト方針を先に説明して
AIを「自動実装マシン」として使うより、調査、提案、小修正、レビュー補助を高速に回す相棒として使う方が、現場では失敗しにくいです。
Composer 2.5が示しているのは、専門モデルの復権である
Composer 2.5の登場は、AIモデルの競争が「汎用モデルの賢さ」だけではなくなっていることを示しています。
これまでは、ClaudeやGPTのような汎用モデルを、どの開発ツールに組み込むかが中心でした。
しかしCursorは逆に、開発環境に合わせてモデルを鍛える方向に進んでいます。
これは、ITシステムで言えば、汎用パッケージをそのまま使うのではなく、業務プロセスに合わせて最適化した専用システムを作るようなものです。
モデル単体の性能だけでなく、次の要素をまとめて最適化する。
- IDE
- CLI
- ツール呼び出し
- ファイル探索
- テスト実行
- 差分管理
- 開発者の短い指示
- エラー時の再試行
この方向は、今後のAI開発支援でかなり重要になるはずです。
汎用AIが強くなっても、特定業務に合わせて鍛えたモデルには価値があります。
ソフトウェア開発は、その代表例になりつつあります。
まとめ: Composer 2.5は「現場の面倒」を減らす方向に進んでいる
Composer 2.5の価値は、単にベンチマークでClaudeやGPTに近づいたことではありません。
より重要なのは、Cursorという開発環境に合わせてモデルを鍛えることで、実際の開発作業の流れに入り込みやすくしていることです。
AIコーディング支援は、すでに「コードを生成してくれる便利機能」から、「リポジトリを読み、ツールを使い、修正し、テストする開発エージェント」へ進化しています。
その中でComposer 2.5は、高性能な汎用モデルを使うだけが正解ではないことを示しています。
IT技術者にとっては、試す価値があります。
特に、毎日の開発で発生する調査、修正、テスト、レビュー前確認のような作業に使うと、効果を感じやすいはずです。
ただし、AIに任せる範囲は明確にする必要があります。
AIは開発者を置き換えるものではなく、開発者が設計判断や品質判断に集中するために、周辺作業を圧縮する道具として使うのが現実的です。
Composer 2.5は、その方向にかなり近づいたモデルだと言えます。
参考情報
- Introducing Composer 2.5 - Cursor
- A technical report on Composer 2 - Cursor
- Composer 2.5 - Cursor Docs
- Kimi K2.5: Visual Agentic Intelligence - arXiv
作成日: 2026年6月16日