JetBrainsが実施した実験では、AIエージェントにRiderのリファクタリングエンジンへの直接アクセスを与えることで、C#タスクの実行方法が根本的に変わり得ることが示された。エージェントにテキストを変更させ、その変更によって何が壊れたのかをコンパイラーで確認させるのではなく、15のタスクを対象としたテストでは、タスクの中央値が157.9秒から26.6秒へ、83%短縮された。また、ツール呼び出し数もタスクあたり17回から6.2回へ減少した。
この機能は、refactoring-codeという組み込みスキルとして提供され、Rider 2026.2.1以降で利用できる。JetBrainsによると、ユーザーが手動で有効化する必要はない。C#コードのリファクタリングを依頼すると、エージェントが自動的にこのスキルを呼び出す。エンジンはReSharperの技術とRiderの解析基盤を利用し、プロジェクト内のシンボルと参照の関係を理解する。
変更してからビルドする方式の問題
このスキルが利用可能になる前、JetBrainsは同じタスクを実行する高度なモデルを観察した。合計2,513回に及ぶさまざまなツールの呼び出しの中で、エージェントは構造的なリファクタリングを直接実行しなかった。それ専用のツールを持っていなかったためである。その代わり、対話的なコマンドを使ってテキストを468回挿入し、gitを422回、sedを392回呼び出し、dotnet buildを163回実行した。
これは、エージェントがリファクタリング操作を避けていたという意味ではない。エージェントは検索とテキスト編集によってリファクタリングを近似し、その結果をビルド結果で評価しようとしていた。JetBrainsは、たとえばシンボルの名前変更には、特定の定義に関連する参照、多相的なメソッド呼び出し、部分クラス、明示的なインターフェース実装、ドキュメント参照を区別する必要があると説明している。こうした関係を単純な正規表現で一貫して保証することはできない。
一方、Riderのエンジンは解決済み構文木上で動作し、各識別子がどの定義に関連付けられているか、各呼び出しがどのオーバーロードを呼び出すか、ソリューション全体における参照の位置を特定する。これにより、タスクの構造的な部分はエンジンに任せられ、エージェントが変更、ビルド、エラーの読み取りを繰り返しながら、こうした関係を徐々に再発見する必要がなくなる。
JetBrainsが測定した内容
評価では、結果を明確に検証できる次の8種類の操作に焦点を当てた。
- シンボルと、そのすべての参照の名前を変更する。
- 一連のステートメントを新しいメソッドへ抽出する。
- 既存の型からインターフェースを抽出する。
- 基底クラスを抽出し、メンバーをそこへ移動する。
- APIのシグネチャを変更し、呼び出し箇所を更新する。
- 型を別の名前空間へ移動し、using文を修正する。
- フォルダー構造に合わせて名前空間を再編成する。
- 他の部分から依存されていない場合に、シンボルを安全に削除する。
タスクには、単純なケースと、呼び出し箇所が多い、または依存関係が複雑に絡み合った、より複雑なケースが含まれていた。両方の条件で同じモデルgpt-5.5をCodex CLI経由で使用し、各タスクをおよそ10回実行した。違いは、refactoring-codeスキルを利用できるかどうかだけだった。比較は記録された実行結果と、対応のあるpermutation検定に基づいて行われた。
実際の結果とコスト
スキルを有効にすると、dotnet buildの実行回数は163回からわずか3回に減少し、評価におけるツール呼び出しの合計も2,513回から926回に減った。テキスト編集がなくなったわけではなく、sedは依然として最も多く使われたツールだった。ただし役割の分担は変化した。通常の編集はテキスト編集ツールが担い、影響がエージェントから直接見えない部分にまで及ぶ可能性のある構造的な変更はエンジンが担った。
95パーセンタイルの所要時間は346.4秒から56.9秒へ短縮された。これは特に、変更、ビルド、エラー処理のサイクルで処理が行き詰まるケースがなくなったことに関係している。タスクあたりのコストの中央値は0.33ドルから0.12ドルへ、成功したタスクあたりのコストは0.52ドルから0.19ドルへ減少した。また、タスクあたりの入力トークン数は436,745から208,524へ、キャッシュ読み取りは2,973,158から1,257,600へ、出力は32,532から15,538へ減少した。
ユーザーにとっての意味
この実験は、エージェントツールの有用性が、モデルがコードを生成する能力だけでなく、呼び出せるツールの種類にも左右されることを示している。15タスク中8タスクでは、スキルを利用できる条件のほうが高速かつ低コストで、より多くのツールを使うこともなく、両方の条件でテストに成功した。基本条件で実行に2分以上かかった6タスクは、82%から94%の範囲で改善した。
ただし、結果があらゆるケースで全面的な成果を意味するわけではない。2つのタスクでは両方の条件が失敗し、スキルを利用できる条件では成功しなかった一方、基本条件では成功したタスクが1つあった。また、4つのタスクはもともと十分に高速だったため、Riderエンジンを呼び出しても経済的なメリットはなかった。そのため、これらの数値は特定のリファクタリング操作におけるスキルの有効性を示すものであり、すべてのタスクが同じ程度に改善することを保証するものではない。
違いを具体的に示すため、JetBrainsはReportExporter型から基底クラスを抽出するタスクを紹介した。スキルなしでは、実行に336.7秒、24回の呼び出し、1.15ドルのコストがかかり、継承、コンストラクター、アクセス権に関するエラーを処理するため、ファイルの変更とビルドの実行を何度も繰り返した。スキルを利用すると、実行時間は19.8秒、呼び出し回数は3回、コストは0.09ドルだった。エージェントはextract_base_class操作を実行し、ExporterBaseを作成し、4つのファイルを更新して11個の参照を書き換えた。
この機能は、Riderをバージョン2026.2.1に更新し、C#ソリューションを開いたうえで、要素の名前変更、インターフェースの抽出、型の移動をエージェントに依頼することで試せる。記事では、「このクラスを整理して」といった一般的な表現ではなく、「OrderProcessorからインターフェースを抽出して」のように、操作名を指定して依頼することを推奨している。