AIコーディングツールの議論を見ていると、どうしても「どのモデルが賢いか」という話ばかりになりがちだ。しかし、実際にTypeScriptのフロントエンドとPythonのバックエンドが混在するような現場で手を動かしていると、モデルの性能よりも「エージェントがどこに常駐しているか」の方がはるかに作業効率を左右することに気づく。
ここ最近、Claude CodeとCursorを併用して開発を進めてみて見えてきたのは、単なるツールの好みの問題ではない。これは、開発環境のアーキテクチャに関する決定的な違いだ。
エディタという「箱」の限界
Cursorの体験は非常に優れている。開いているファイルやコードベースのコンテキストを理解し、エディタの中で完結する作業であれば、これ以上ないほど快適にコードを生成してくれる。最近のComposer 2のアップデートを見ても、エディタ内での操作性は極まっている。
だが、現実のプロジェクトはエディタの中で完結しない。
フロントエンドのビルドプロセスを走らせ、バックエンドのDockerコンテナを立ち上げ、マイグレーションスクリプトを叩く。こういったシステムの「実行」と「状態変化」を伴う作業は、すべてターミナルで行われる。CursorのAIに「DBのマイグレーションがこけたから直して」と頼む場合、ターミナルのエラー出力をコピペしてAIに渡すという、非常に泥臭い中間作業が発生する。エディタのAIは、実行環境から切り離されているからだ。
ターミナルネイティブなClaude Codeの衝撃
対して、Claude Codeのようにターミナル上で直接動くエージェントのアプローチは根本的に違う。
彼らはファイルシステムとコマンド実行環境のど真ん中にいる。ビルドコマンドがこければ自分でログを読み、原因を推測してファイルを修正し、再度コマンドを実行する。TypeScriptの型エラーとPythonの依存関係の不整合が同時に起きていても、ターミナルから俯瞰しているエージェントにとっては、ただの「標準入出力のループ」として処理できる。
この「実行環境そのものにAIが住んでいる」という感覚は、一度味わうとかなり強烈だ。エディタの画面領域という狭いコンテキストから解放され、プロジェクト全体を操作可能なシステムとして認識してくれる。
使い分けの境界線
じゃあ全部ターミナルのClaude Codeに任せればいいのかというと、もちろんそんなことはない。
UIの細かなマージン調整や、複雑な関数のリファクタリングなど、「コードの形や構造を見ながら考える」作業においては、Cursorのようなエディタ統合型が圧倒的に強い。視覚的なフィードバックループの短さは、ターミナルベースのツールでは到底追いつけない。
今のところ、私はこんな風に割り切っている。
コードの「見た目」や「構造」をこねくり回す作業はCursorにやらせる。
プロジェクトの「実行」や「環境の復旧」、複数スタックにまたがるトラブルシューティングはClaude Codeに丸投げする。
どっちが優れているかという議論は、そろそろ終わりにしたい。重要なのは、自分が今直面しているタスクが「エディタの文脈」で解決すべきものなのか、「ターミナルの文脈」で解決すべきものなのかを見極めることだ。結局のところ、AIアシスタントは万能の魔法ではなく、ただの新しいインターフェースに過ぎない。それをどこに配置してどう使うかを決めるのは、まだ人間の仕事として残っている。