AI IDE とは、AI がオプションの拡張機能ではなく、アーキテクチャの中核的な構成要素となっている統合開発環境である。AI IDE におけるルールの分類法と進化：マイニングと調査による研究 が引く区別は、プラグイン方式との対比である。たとえば VS Code に GitHub Copilot 拡張機能を入れた構成では、アシスタントはホストのエディタが課す制約の中で動作するため、実行時の状態、エディタ内部のシグナル、きめ細かな対話データへのアクセスが制限される。AI IDE では、モデルは代わりにエディタの中核的な基盤に統合されており、この研究は、それこそがコード補完を超えた能力を可能にしていると論じる。自律的なタスク分解、複数ファイルにまたがるリファクタリング、アーキテクチャ上の推論、コンテキストを考慮した生成、そしてプロジェクト固有の設定への継続的な整合である。
用法
この研究が用いるカテゴリーは、部分的には共通の機能によって定義されている。研究が調べるツールはどれも、コード生成やチャットの際に IDE が従わなければならない AI IDE ルール を開発者が定義できるようになっている。それを根拠に研究対象とされたのが、Cursor、Windsurf、Trae、Qoder、Kiro の五つである。
AI IDE で構築されたと明示されている 83 のプロジェクトをこの研究が収集した結果からは、当時このカテゴリーがどこで使われていたかがうかがえる。コードベースでは TypeScript が 50.6% で圧倒的に多く、Python が 14.4%、JavaScript が 9.6% と続く。ドメインは Web アプリケーション開発が大半を占め、フルスタック、フロントエンド、バックエンドのプロジェクトを合わせると 56.6% になる。プロジェクトは小規模で、半数以上はコミット数が 50 未満であり、個人開発者か 2〜3 人のチームが大多数を占める。研究は、それらの多くが 2025 年 6 月から 2025 年 9 月の間に作られたと報告している。
調査の側からは、同じ問いについて別の見方が得られる。回答者は、絞り込まれたプロジェクト群についてではなく、自身の実践について答えているからである。99 人の実務家のうち、最も広く採用されていたのは Cursor で 57 人、僅差で VS Code と Copilot の構成が 51 人（つまり AI IDE ではなくプラグイン方式）と続き、Kiro が 37 人、Trae が 24 人、Windsurf が 23 人、Qoder が 16 人だった。さらに 34 人が Antigravity を使っていると回答し、Claude Code、Codex、OpenCode が「その他」の選択肢の中で挙げられた。
適用される場面
この用語が役に立つのは、それが名指すアーキテクチャ上の区別が実際に違いを生む場面、つまりエディタの状態やプロジェクトのコンテキストへのモデルのアクセスの深さこそが論点になっている場面である。そうでない場合は、「AI コーディングツール」という言い方のほうが、より少ない前提で同じ範囲をカバーする。上の調査データがその最もわかりやすい例である。AI IDE も使っている開発者の間で、プラグイン構成が採用数で 2 位につけており、研究はそれを AI IDE として扱わずに別に数えている。
研究は、アーキテクチャ上の特徴づけと、ユーザー定義のルールをサポートする五つのツールという独自の選定を超える、所属判定のための運用上のテストを示していない。そのため、あるツールがどちらに入るかは判断に委ねられる。研究はまた、このエコシステムが急速に進化していること、つまり基盤となるファウンデーションモデルもルール注入の仕組みも頻繁に更新されることを指摘しており、自らの知見を現在のコンテキストエンジニアリングのプラクティスのスナップショットとして提示している。
関連用語
- AI IDE ルール — これらのツールが共有する設定の仕組み
- AI IDE におけるルールの分類法と進化：マイニングと調査による研究 — この説明の出典となった研究
- AI コーディングエージェント — このカテゴリーのエージェント型の兄弟分
- エージェント型コーディング — これらのツールが対象とするプラクティス