Cursor CLIとは？通常のCursorとの違いから使い方・開発ワークフローまで徹底解説

Cursorを使っていると、エディタ上でAIに質問したり、コードを書き換えてもらったりするだけでも十分便利です。

ただ、開発に慣れてくると、次のように感じる場面も増えてきます。

ターミナルから直接プロジェクトを開きたい
VS Codeの code . のようにCursorもコマンドで起動したい
AIを使った作業を、普段の開発フローにもっと自然に組み込みたい

このようなときに役立つのが、Cursor CLIです。

結論からお伝えすると、Cursor CLIはCursor本体とは別のエディタではなく、ターミナルからCursorを素早く起動したり、ターミナル上でAI Agentを使ったりするための仕組みです。

特に、プロジェクトフォルダへ移動してから cursor . と入力するだけでCursorを開けるので、複数の学習用フォルダを行き来するときは想像以上に作業開始がラクになります。

一方で、Cursor CLIには cursor . のようにCursorを開く使い方だけでなく、cursor-agent のようにターミナル上でAI Agentを使う文脈もあります。ここを混同すると分かりにくくなるため、この記事では両者の違いも含めて、導入方法や開発ワークフローまで順番に紹介します。

目次−

Cursor CLIの基本｜Cursorとの違いとできること

Cursor CLIとは何か

Cursor CLIとは、ターミナルからCursorを起動したり、プロジェクトフォルダを直接Cursorで開いたり、ターミナル上でAI Agentを使ったりするためのコマンドライン機能です。

普段Cursorを使う場合は、アプリのアイコンをクリックして起動し、そこからフォルダを選んで開く流れになります。

一方でCursor CLIを使うと、ターミナルで作業しているディレクトリから、そのままCursorを開けます。

代表的なコマンドは次のとおりです。

cursor .

この cursor . は、現在いるフォルダをCursorで開くための基本コマンドです。

実際に使ってみると、アプリ版のCursorを起動してフォルダを選び直すよりも、cd プロジェクト名 のあとに cursor . と打つだけのほうがかなりスムーズでした。特に複数のプロジェクトを行き来するときは、作業開始までの小さな手間が減ります。

VS Codeを使ったことがある場合は、code . で現在のフォルダをVS Codeで開く操作に近いと考えると分かりやすいでしょう。

ただし、Cursor CLIという言葉は、単にCursorを起動するための cursor コマンドだけを指す場合もあれば、ターミナル上でAI Agentを動かす cursor-agent を含めて使われる場合もあります。

そのため、最初は「cursor . はフォルダをCursorで開くもの」「cursor-agent はターミナル上でAI Agentを使うもの」と分けて理解しておくと迷いにくいです。

通常のCursorとCursor CLIの違い

通常のCursorは、VS CodeをベースにしたAI対応コードエディタです。

画面上でファイルを開き、AIチャットやインライン編集、Composer、Agentなどを使いながらコードを書いていきます。

一方でCursor CLIは、そのCursorをターミナルから扱うための仕組みです。

違いを整理すると、次のようになります。

項目	通常のCursor	Cursor CLI
主な役割	AI対応コードエディタとして使う	ターミナルからCursorを起動したり、Agentを使ったりする
操作場所	エディタ画面	ターミナル、PowerShell、シェル
代表的な使い方	AIチャット、コード生成、編集、デバッグ	`cursor .` で現在のフォルダを開く、`cursor-agent` でターミナル上のAgentを使う
向いている作業	コードを書く、読む、修正する	開発フォルダから素早くCursorを開く、自動化やターミナル中心の作業に組み込む

つまり、Cursor CLIはCursorそのものを置き換えるものではありません。

コードを読んだり、AIチャットで質問したりするだけなら、通常のCursorでも十分に感じる場面は多いです。ただ、新しいプロジェクトを作ってすぐ開く作業や、ターミナルで移動してから開発を始める流れでは、Cursor CLIの便利さを実感しやすいでしょう。

Cursor・CLI・cursorコマンドの位置づけ

言葉が似ているので、最初に整理しておきましょう。

ここを理解しておくと、Cursor CLIの使い方が一気に分かりやすくなります。

Cursorとは

Cursorは、AI機能を中心に設計されたコードエディタです。

VS Codeをベースにしているため、VS Codeに慣れている場合は操作感もかなり近く感じるはずです。

ファイル編集、拡張機能、ターミナル、Git連携といった基本機能に加えて、次のようなAI機能が使えます。

AIチャット
コード生成
エラー修正
リファクタリング支援
複数ファイルにまたがる編集

AIを使いながらコードを書きたい場合に、かなり心強い開発環境です。

CLIとは

CLIは「Command Line Interface」の略です。

マウスで画面を操作するのではなく、ターミナルやコマンドプロンプトに文字を入力して操作する仕組みを指します。

macOSならターミナルやiTerm2、WindowsならPowerShellやWindows Terminal、WSLのシェルなどがCLIを使う場所になります。

CLIに慣れていない場合、最初は少し難しく感じるかもしれません。その場合は、無理に最初から覚えようとするより、まず通常のCursorに慣れてから、作業開始を短縮したくなった段階で試すくらいでも十分です。

cursorコマンドとは

cursor は、ターミナルからCursorを呼び出すためのコマンド名です。

たとえば、プロジェクトフォルダに移動してから次のように入力します。

cursor .

すると、そのフォルダをCursorで開けます。

この流れができるようになると、アプリ一覧からCursorを探して起動し、フォルダを選択する手間が減ります。

なお、ターミナル上でAI Agentを動かす場合は、cursor-agent というコマンドが使われることがあります。cursor と cursor-agent は役割が違うため、最初に分けて覚えておくと混乱しにくいです。

Cursor CLIでできる主なこと

Cursor CLIを使う目的は、開発フローを短くすることです。

代表的な使い方を順番に紹介します。

現在のフォルダをCursorで開く

一番よく使うのが cursor . です。

cursor .

. は「現在のフォルダ」を意味します。

つまり、今ターミナルで開いているフォルダを、そのままCursorで開くコマンドです。

複数の学習用フォルダや小さな検証用プロジェクトを行き来するときは、この使い方だけでも十分に便利です。

特定のフォルダをCursorで開く

フォルダ名を指定してCursorを開くこともできます。

cursor my-project

すでに作成済みの my-project フォルダをCursorで開きたい場合に使えます。

新規プロジェクト作成後にすぐCursorを開く

新しいフォルダを作って、そこに移動し、Cursorで開く流れは次のようになります。

mkdir my-ai-app
cd my-ai-app
cursor .

この3行だけで、空のプロジェクトフォルダを作成し、Cursorで開くところまで進められます。

地味に見えますが、毎日の開発ではこの小さな時短がかなり効きます。

VS Codeの代わりにCursorを使う

これまでVS Codeで次のように開いていた場合、

code .

Cursorを使うなら、次のように置き換えます。

cursor .

この違いだけでも、ターミナル中心の開発ではかなり自然にCursorを使えるようになります。

ただし、環境によっては code . の挙動やPATHの順番が変わり、VS CodeではなくCursorが開くようなケースもあります。VS CodeとCursorを両方使う場合は、どちらのコマンドでどちらが開くのかを一度確認しておくと安心です。

CursorのAI機能とCLIの関係

Cursor CLIは、AIモデルを直接ターミナルで動かすためだけの機能というより、CursorというAIエディタに素早く入るための入口として考えると分かりやすいです。

一方で、cursor-agent を使う場合は、ターミナル上でAI Agentに指示を出し、対話的に作業したり、スクリプトや自動化に組み込んだりする使い方もあります。

最初からすべてを覚える必要はありません。まずは cursor . でプロジェクトを開く使い方を押さえ、その後で必要に応じて cursor-agent や自動化の使い方に進むのが分かりやすいです。

Cursorを開いた後は、エディタ内で次のようなAI機能を使えます。

AIチャット

AIチャットでは、コードについて質問したり、エラーの意味を確認したりできます。

たとえば、関数を選択してから「この処理を分かりやすく説明して」と聞けば、選択範囲を前提にした解説を返してくれます。

すぐにコードを書き換えるというより、理解を深めたいときや方針を相談したいときに便利です。

インライン編集

インライン編集は、ファイル内の一部を選択して、その場でAIに書き換えてもらう機能です。

たとえば、次のような依頼ができます。

この関数を読みやすくして

例外処理を追加して

TypeScriptの型を厳密にして

細かい修正を素早く行いたい場合に向いています。

Composer

Composerは、複数ファイルをまたぐ変更や、新しい機能の追加に使いやすい機能です。

単一ファイルの修正ではなく、アプリ全体の構成を見ながらコード生成や修正を進めたいときに役立ちます。

たとえば、ログイン画面の追加や、Todoアプリへの機能追加などに向いています。

Agent

Agentは、AIが必要なファイルを探し、コードを修正し、場合によってはコマンドを実行しながら作業を進める機能です。

エラー修正、リファクタリング、テスト実行を含む作業で力を発揮します。

ただし、便利な反面、想定外のファイルまで変更されることもあります。

実際にAgentへ修正を任せると、複数ファイルが変更されることがあります。そのため、差分を見ずにAcceptするのは危険です。

Agentに大きな作業を任せる前には、Gitで現在の状態を保存しておくのがおすすめです。

対応環境と日本語での使いやすさ

CursorはWindows、macOS、Linux系環境で使えるコードエディタです。

CLIも、環境に合わせて設定すればターミナルから利用できます。

ただし、OSやターミナルの種類によって、PATH設定やコマンドの認識に差が出ることがあります。特にWindows、WSL、Git Bash、Linux系環境では、同じ手順で必ず動くと決めつけないほうが安全です。

Windowsでの利用

Windowsでは、PowerShell、コマンドプロンプト、Windows Terminalなどから cursor コマンドを使えます。

WSLを使っている場合は、WSL上のプロジェクトをCursorで開く使い方もできます。

ただし、環境によってPATH設定や連携設定が必要になることがあります。

Git Bashなど、使っているシェルによってはコマンドが認識されないこともあるため、まずはPowerShellやWindows Terminalで動作確認しておくと切り分けしやすいです。

macOSでの利用

macOSでは、標準のターミナルやiTerm2から cursor コマンドを使えます。

HomebrewでCursorをインストールする方法もあるため、ターミナル中心で開発している場合は導入しやすいです。

公式サイトからアプリを入れた場合は、Cursor内のコマンドパレットからShell Commandを設定すると、ターミナルから cursor . が使えるようになります。

日本語での指示

CursorのAI機能は、日本語での指示にも対応しています。

たとえば、次のような指示ができます。

このコードをリファクタリングして

このエラーの原因を説明して

Reactコンポーネントとして分割して

英語のプロンプトに慣れていなくても、普段使っている言葉で指示できる点は大きな魅力です。

ただし、指示が曖昧だと期待と違う修正になることがあります。日本語で問題ありませんが、対象ファイル、目的、制約、出力形式はできるだけ具体的に伝えましょう。

料金体系を考えるときの見方

Cursorには無料枠や有料プランが用意されています。

ただし、料金や利用条件は変更される可能性があります。

実際に使い始める前には、必ず公式サイトで最新情報を確認しましょう。

まず試すなら無料枠

Cursorが自分の開発スタイルに合うか確認したい段階では、無料枠から始めるのが良いです。

cursor . でプロジェクトを開き、AIチャットやコード生成を少し試すだけでも、使い勝手はかなり分かります。

まずは「ターミナルからCursorを開くと作業がラクになるか」を確認したいだけなら、いきなり有料プランを前提にしなくても判断しやすいです。

毎日使うなら有料プランを検討

毎日コードを書く場合や、Agent、Composerを頻繁に使う場合は、有料プランのほうが作業効率を上げやすくなります。

AIへの依頼回数が増えるほど、無料枠では足りなくなる可能性があります。

特に、Agentに複数ファイルの修正やエラー調査を何度も依頼する場合は、利用量が増えやすい点も意識しておきましょう。

APIキー運用は慎重に考える

OpenAIやAnthropicなどのAPIキーを自分で設定して使う方法もあります。

ただし、API利用は従量課金になるため、Agentで大量に処理させると想定より費用が増えることがあります。

利用量を把握できるまでは、定額プランのほうが安心して使いやすい場面もあるでしょう。

APIキーを使う場合は、料金だけでなく、キーの管理方法にも注意が必要です。誤ってコード内に直接書いたり、Git管理に含めたりしないようにしましょう。

Cursor CLIの導入方法｜Windows・macOSでのセットアップ

インストール前に確認しておきたいこと

Cursor CLIを使うには、まずCursor本体がインストールされている必要があります。

CLIだけを単独で使うというより、Cursor本体をインストールしたうえで、ターミナルから cursor コマンドを呼び出せるようにするイメージです。

ターミナル上でAI Agentを使いたい場合は、cursor-agent の導入や認証が必要になることがあります。最初は cursor . が動くかを確認し、慣れてきたらAgent CLIの利用を検討すると進めやすいです。

必要な環境

導入前に、次のものを確認しておきましょう。

ターミナル

macOSなら標準のターミナル、WindowsならPowerShellやWindows Terminalを使います。

WSLを使う場合は、UbuntuなどのLinuxシェルから開くケースもあります。

同じWindowsでも、PowerShell、Windows Terminal、Git Bash、WSLでは挙動が変わることがあります。うまく動かないときは、まずどのターミナルで試しているのかを確認しましょう。

Cursor本体

Cursor公式サイトからアプリをダウンロードしてインストールします。

macOSでは、Homebrewを使ったインストールも可能です。

PATH設定

cursor コマンドをターミナルのどこからでも使うには、PATH設定が必要です。

PATHとは、ターミナルがコマンドを探しに行く場所のリストです。

Cursorの実行ファイルがある場所をPATHに登録しておくと、どのフォルダにいても cursor と入力するだけで起動できます。

最初に cursor . を入力しても反応しない場合、まず疑うべきはPATH設定です。設定後もターミナルを再起動しないと反映されないことがあるため、ここはかなりつまずきやすいポイントです。

WindowsでCursor CLIを使う手順

Windowsでは、まずCursor本体をインストールします。

公式インストーラを使う

Cursorの公式サイトからWindows用インストーラをダウンロードします。

インストーラを実行し、画面の指示に沿って進めれば、Cursor本体がインストールされます。

インストール後、PowerShellやWindows Terminalを開き、次のコマンドを試します。

cursor .

これでCursorが起動し、現在のフォルダが開けば設定は完了です。

もし動かない場合は、Cursor本体が入っていないのではなく、ターミナル側が cursor コマンドを見つけられていないだけの可能性があります。

Windowsでcommand not foundが出る場合

cursor と入力しても動かない場合は、PATHが正しく設定されていない可能性があります。

表示例は次のようなものです。

command not found: cursor

PowerShellでは、コマンドが認識されないというエラーが出ることもあります。

この場合は、Windowsの環境変数を確認しましょう。

PATH確認の流れ

Windowsの検索欄で「環境変数」と入力し、「システム環境変数の編集」または「環境変数を編集」を開きます。

次に、ユーザー環境変数の中にある Path を選び、Cursorのインストール先が登録されているか確認します。

一般的には、次のような場所にCursor関連のファイルが入ります。

C:\Users\ユーザー名\AppData\Local\Programs\cursor\resources\app\bin

環境によってパスは異なることがあるため、自分のPCでCursorがインストールされている場所を確認して追加しましょう。

追加後は、開いているターミナルを閉じて、もう一度起動します。

PATHの変更は、ターミナルを再起動しないと反映されないことがあります。

実際に、PATH設定が原因だと分かったあとも、ターミナルを再起動するまで反映されずに焦ることがあります。設定したのに動かない場合は、まずターミナルを閉じて開き直しましょう。

WSLでCursorを使うときの考え方

WSLを使っている場合、Linux側のターミナルからWindows側のCursorを開きたい場面があります。

たとえば、WSL内のプロジェクトフォルダで次のように入力します。

cursor .

これでCursorが開けば、そのままWSL上のファイルを編集できます。

ただし、WSL連携は環境によって挙動が変わることがあります。

うまく動かない場合は、Windows側でCursorコマンドが使えるか、WSL側から呼び出せるPATHになっているかを確認しましょう。

WSLやLinux系環境では、Command Paletteの項目やパスの扱いがmacOSやWindowsと違うことがあります。動かないときは「Cursor本体の問題」と決めつけず、シェル、PATH、実行場所を順番に確認するのがおすすめです。

macOSでCursor CLIを使う手順

macOSでは、公式サイトからアプリをダウンロードする方法と、Homebrewを使う方法があります。

Homebrewでインストールする方法

Homebrewを使っている場合は、次のコマンドでCursorをインストールできます。

brew install --cask cursor

インストール後、ターミナルで次のコマンドを試します。

cursor .

現在のフォルダがCursorで開けば設定は完了です。

もし cursor-agent を使う場合は、別途Cursor CLIのインストールコマンドやPATH追加が必要になることがあります。cursor . が動くことと、cursor-agent が動くことは分けて確認しましょう。

公式サイトからインストールした場合のPATH設定

公式サイトから .dmg ファイルをダウンロードしてインストールした場合、cursor コマンドがすぐに使えないことがあります。

その場合は、CursorのコマンドパレットからPATHに登録します。

手順は次のとおりです。

Cursorを起動する
Cmd + Shift + P を押してコマンドパレットを開く
検索欄に shell と入力する
Shell Command: Install 'cursor' command in PATH を選択する
ターミナルを再起動する
cursor . を実行する

これで、ターミナルからCursorを起動できるようになります。

VS Codeから移行するときのポイント

CursorはVS Codeをベースにしているため、VS Codeの設定やキーバインド、テーマ、拡張機能を引き継ぎやすいのが特徴です。

初回起動時に、VS Codeの設定をインポートする画面が表示されることがあります。

普段使っているテーマや拡張機能をそのまま使いたい場合は、インポートを選ぶと移行しやすくなります。

ただし、VS CodeとCursorを併用する場合は、code . と cursor . の使い分けを確認しておきましょう。PATHの順番や設定によって、意図しないエディタが開くことがあるためです。

code . から cursor . への置き換え

これまでVS Codeを使っていた場合、ターミナルでは次のように開いていたかもしれません。

code .

Cursorを使う場合は、次のように置き換えます。

cursor .

たったこれだけですが、作業フローはかなり変わります。

ターミナルでプロジェクトを作成し、そのままCursorで開き、AIを使いながらコードを書き始める流れが自然になります。

普段からターミナルで cd して作業フォルダへ移動している人ほど、cursor . の便利さを感じやすいです。反対に、いつもアプリをクリックして特定のプロジェクトだけを開いている人は、最初から無理に覚える必要はありません。

最初に設定しておきたい項目

Cursorをインストールしたら、すぐに開発を始める前に設定を確認しておくと安心です。

アカウントにログインする

Cursorの設定画面からアカウントにログインします。

ログインしていないと、AI機能が制限されることがあります。

cursor-agent を使う場合も、初回利用時にブラウザ認証が必要になることがあります。認証が完了していないと、コマンド自体は入っていてもAI機能が使えないことがあるため注意しましょう。

モデル設定を確認する

Cursorでは、利用するAIモデルを選べます。

モデルによって、応答の速さ、コード生成の精度、長い文脈の扱いやすさが変わります。

最初は標準で選ばれているモデルを使い、必要に応じて切り替えるのが分かりやすいです。

短い質問なら速度重視でも十分なことがありますが、複数ファイルをまたぐ修正や設計に関わる相談では、精度を重視したモデルを選ぶほうが安定しやすくなります。

Privacy Modeを確認する

仕事や個人開発で機密情報を扱う場合は、プライバシー関連の設定を確認します。

特に会社のコードや非公開プロジェクトを扱う場合は、利用規約やチームのルールに沿って設定する必要があります。

AIに何を送ってよいのかは、必ず事前に確認しておきましょう。

顧客情報、認証情報、未公開仕様、商用コードなどを扱う場合は、Cursorの設定だけでなく、チーム側のルールも確認しておくと安心です。

ターミナルから起動できるか確認する

最後に、実際にターミナルで次のコマンドを実行します。

cursor .

これが動けば、Cursor CLIの基本設定は完了です。

あわせて、ターミナルを再起動しても同じように動くか確認しておくと、PATH設定がきちんと反映されているか判断しやすくなります。

cursorコマンドの使い方｜ターミナルから開発を始める基本操作

基本は cursor . を覚える

Cursor CLIで最初に覚えるコマンドは、ほぼこれだけです。

cursor .

現在のフォルダをCursorで開くコマンドです。

開発では、ターミナルでプロジェクトフォルダへ移動し、その場所でエディタを開く流れがよくあります。

cd my-project
cursor .

この2行で、目的のプロジェクトをCursorで開けます。

アプリ版のCursorを毎回起動してフォルダを選ぶより、プロジェクト移動から作業開始までがかなり短くなります。

新しいプロジェクトを作ってCursorで開く

新しいフォルダを作り、その中で開発を始める場合は、次のように操作します。

mkdir sample-web-app
cd sample-web-app
cursor .

この状態でCursorが開いたら、空のフォルダに対してAIへ次のように依頼できます。

HTML、CSS、JavaScriptで簡単なアプリを作って

空の状態からでも、AIと一緒に開発を始められるのがCursorの強みです。

この流れは、学習用の小さなプロジェクトを作って試すときに特に便利です。まずフォルダを作り、移動して、Cursorを開く。この一連の流れが短くなるだけでも、始めるハードルが下がります。

フレームワークの作成コマンドと組み合わせる

Cursor CLIは、フレームワークのプロジェクト作成コマンドと組み合わせると便利です。

たとえば、Viteを使う場合は次のような流れになります。

npm create vite@latest my-vite-app
cd my-vite-app
npm install
cursor .

プロジェクトを作成し、依存関係をインストールし、そのままCursorで開く流れです。

Cursorを開いた後は、ComposerやAgentを使って、コンポーネント追加、CSS修正、エラー対応などを進められます。

ただし、生成直後のプロジェクトでも、AIに大きな変更を一気に任せる場合は差分確認が必要です。最初にGit管理を始めておくと、うまくいかなかったときに戻しやすくなります。

既存プロジェクトを開く

すでにあるプロジェクトを開く場合は、フォルダに移動してから cursor . を実行します。

cd existing-project
cursor .

または、現在いる場所からフォルダ名を指定して開くこともできます。

cursor existing-project

複数のプロジェクトを行き来する場合、ターミナルから直接開けるのはかなり便利です。

学習用フォルダ、検証用フォルダ、既存プロジェクトなどを行き来する人ほど、この使い方のメリットは大きいです。

Cursor内で使うAIモードの違い

Cursor CLIでプロジェクトを開いた後は、Cursor内のAI機能を使って開発を進めます。

主に使うのは、次の4つです。

Chat
インライン編集
Composer
Agent

ざっくり言えば、理解したいときはChat、一部だけ直したいときはインライン編集、複数ファイルをまたぐ変更はComposerやAgentという使い分けです。

Chatでコードを相談する

Chatは、コードについて質問したり、エラーの原因を聞いたりするのに向いています。

ショートカットは環境によって異なりますが、macOSでは Cmd + L、Windowsでは Ctrl + L が使われることがあります。

たとえば、次のような質問ができます。

この関数の処理を分かりやすく説明して

このエラーの原因を候補ごとに整理して

このコードをより読みやすくする改善案を出して

Chatは、すぐにコードを書き換えさせるというより、理解を深めたり、方針を決めたりするときに使いやすいです。

コードを読むだけ、エラーの意味を確認するだけ、方針を相談するだけなら、通常のCursorのChatでも十分な場面が多いです。

インライン編集で一部だけ修正する

インライン編集は、選択したコードの一部をその場で修正したいときに使います。

たとえば、関数を選択して次のように指示します。

この関数にエラーハンドリングを追加して

変数名を分かりやすくして、処理の意味が伝わるようにして

TypeScriptの型を追加して

一部のコードだけを素早く直したい場合は、Chatよりもインライン編集のほうが使いやすいことがあります。

変更範囲が狭いので、AIに任せたあとの確認もしやすいです。

Composerで複数ファイルをまとめて変更する

Composerは、複数ファイルにまたがる変更を依頼するときに便利です。

たとえば、次のような依頼が向いています。

ログイン画面を追加して、必要なコンポーネントとCSSを作成して

既存のTodoアプリにカテゴリ機能を追加して

APIクライアントを分離して、呼び出し部分も書き換えて

複数のファイルを作成・編集するため、変更内容は必ず確認してから反映しましょう。

Composerは便利ですが、作業範囲が広がるほど確認すべき差分も増えます。小さな変更なら便利でも、大きな変更ではGitで保存してから進めるほうが安心です。

Agentで自律的に作業させる

Agentは、AIがプロジェクトを見ながら必要な作業を進めるモードです。

たとえば、エラー修正を依頼する場合は次のように伝えます。

ターミナルに出ているエラーを確認して、原因を特定し、アプリが起動する状態まで修正して

Agentは、必要に応じてファイルを読み、修正し、コマンドを実行しながら進めることがあります。

便利な反面、思っていないファイルまで変更される可能性があります。

そのため、作業前にGitでコミットしておくと安心です。

特に、複数ファイルをまたぐ修正では、変更内容を見ずにAcceptするのは危険です。Agentはあくまで作業を助ける存在であり、最終判断は自分で行う必要があります。

Outputログの確認方法

CursorでAIや拡張機能を使っていると、内部でエラーが起きることがあります。

その場合は、Outputパネルを確認しましょう。

ログを見る流れ

Cursor下部のパネルを開く
Outputまたは出力タブを選ぶ
ドロップダウンからCursor関連のログを選ぶ
エラーや警告を確認する

AIが応答しない、インデックス作成が進まない、ファイルをうまく読み込まないといった場合、ログを見ると原因が分かることがあります。

「なんとなく動かない」で止まるより、ログを見てエラー内容を確認したほうが、次に何を試せばいいか判断しやすくなります。

よく使うショートカット

Cursorを使うなら、次の3つはよく使います。

操作	macOS	Windows
Chatを開く	Cmd + L	Ctrl + L
インライン編集	Cmd + K	Ctrl + K
Composerを開く	Cmd + I	Ctrl + I

環境や設定によってショートカットが異なる場合があります。

その場合は、キーボードショートカット設定から確認しましょう。

.cursorrulesでAIの振る舞いを整える

Cursorでは、プロジェクトごとのルールをAIに伝えるために .cursorrules のような設定ファイルを使うことがあります。

たとえば、次のような内容です。

# プロジェクトルール

- コードを変更したら、必要に応じてテストを実行すること
- コンポーネントは src/components に作成すること
- 既存の命名規則に合わせること
- 省略したコードではなく、実際に動くコードを書くこと

このようなルールを用意しておくと、AIに毎回同じ説明をしなくても、プロジェクトの方針を意識した提案を受けやすくなります。

特にチーム開発や長く続けるプロジェクトでは、命名規則、ディレクトリ構成、テスト方針などをルール化しておくと、AIの出力がぶれにくくなります。

コマンドエラーの基本的な直し方

Cursor CLIでよくあるエラーは、PATH関連です。

command not found: cursor

このエラーは、ターミナルが cursor コマンドを見つけられていない状態です。

対処法は次のとおりです。

Cursor本体がインストールされているか確認する
PATHにCursorのコマンドが登録されているか確認する
CursorのコマンドパレットからShell Commandを再設定する
ターミナルを再起動する

初心者が特につまずきやすいのは、PATHを設定したつもりでも、ターミナルを再起動していないケースです。設定を変えたら、まずターミナルを開き直してから再度試してみましょう。

Permission denied

Permission denied は、権限が足りない場合に出るエラーです。

Windowsなら管理者権限でターミナルを開く、macOSなら対象フォルダの権限を確認する、といった対応が必要です。

Cursorは開くが対象フォルダが開かない

この場合は、コマンドを実行している場所を確認します。

macOSやLinuxでは、次のコマンドで現在の場所を確認できます。

pwd

WindowsのPowerShellでは次のコマンドが使えます。

Get-Location

思っていたフォルダにいない場合は、cd で移動してから再度 cursor . を実行しましょう。

cursor . の . は「今いる場所」を開くという意味なので、現在地を間違えると別のフォルダを開いてしまいます。

Cursor CLIを使った開発ワークフロー実例

ターミナルから新規プロジェクトを始める流れ

実際にCursor CLIを使うときは、ターミナルでプロジェクトを作り、そのままCursorで開く流れが基本になります。

たとえば、シンプルなWebアプリを作る場合は次のように始めます。

mkdir digital-clock-app
cd digital-clock-app
cursor .

Cursorが開いたら、Composerを起動して次のように依頼します。

HTML、CSS、JavaScriptでデジタル時計のシングルページアプリを作ってください。ファイルは index.html、style.css、script.js に分けてください。

このように、最初からファイル構成を指定すると、AIの出力が安定しやすくなります。

「何を作るか」「どのファイルに分けるか」「どんな動きにするか」を先に伝えると、AIも判断しやすくなります。

コード生成後は差分を確認する

Cursorがコードを生成すると、変更内容が差分として表示されます。

ここで大切なのは、すぐにすべてを承認しないことです。

差分を見ると、追加されたコード、削除されたコード、変更されたコードが確認できます。

確認したいポイント

想定していないファイルが作られていないか
不要なライブラリが追加されていないか
APIキーや個人情報が含まれていないか
既存コードの重要な部分が消されていないか
ファイル名やディレクトリ構成が意図どおりか

問題なければAcceptします。

違和感がある場合はRejectするか、追加で修正指示を出しましょう。

AgentやComposerは便利ですが、差分を確認しないまま進めると、気づかないうちに重要な処理が書き換わる可能性があります。小さな変更でも、Accept前の確認はクセにしておくと安心です。

AIに大枠を作らせて手動で仕上げる

Cursorを使うと、AIにすべて任せたくなるかもしれません。

ただ、実際にはAIに大枠を作らせて、人間が仕上げる使い方が安定します。

たとえば、デジタル時計アプリなら、AIにHTML構造、CSSの基本デザイン、JavaScriptの時刻更新処理を作ってもらいます。

その後、自分で細かい余白、色、フォント、アニメーションを調整します。

AIは作業の初速を上げるのが得意です。

一方で、細かな好みやサービス固有の品質判断は自分で確認する必要があります。

「AIが作ったから完成」ではなく、「AIにたたき台を作ってもらい、自分で確認して仕上げる」と考えるほうが失敗しにくいです。

エラーが出たときのAgent活用

開発中に次のようなエラーが出ることがあります。

TypeError: Cannot read properties of null

このようなエラーは、JavaScriptで対象の要素が見つからないまま処理しようとしたときによく出ます。

Cursorでは、Agentに次のように依頼できます。

ターミナルに表示されているエラーの原因を調べて、必要なファイルを修正し、アプリが正常に動作する状態にしてください。

Agentは、関連ファイルを読み、原因を探し、修正案を出します。

場合によっては、アプリを起動するコマンドやテストコマンドの実行を提案します。

ただし、Agentに任せる範囲が広いほど変更範囲も広がります。エラー修正を依頼するときも、対象ファイルやゴールをできるだけ具体的に伝えましょう。

Agentに任せる前にGitで保存する

Agentは便利ですが、複数ファイルを一気に変更することがあります。

そのため、Agentに大きな作業を任せる前にはGitで現在の状態を保存しておきましょう。

git status
git add .
git commit -m "before agent changes"

この状態であれば、AIの変更がうまくいかなかった場合でも元に戻せます。

git restore .

または、コミット単位で戻すこともできます。

AIを使った開発では、Gitの重要性がさらに高くなります。

実際にAgentへ修正を任せる前には、必ず git status を確認してからコミットするように意識したほうが安全です。複数ファイルが変更されることもあるため、作業前の保存はかなり大事です。

.gitignoreを必ず確認する

AIにプロジェクトを作らせると、ログファイル、ビルド成果物、環境変数ファイルなどが作られることがあります。

特に注意したいのが .env です。

.env にはAPIキーや秘密情報を書くことがあります。

GitHubなどに公開してしまうと危険です。

.gitignore には、少なくとも次のような項目を入れておきましょう。

node_modules
dist
.env
.DS_Store

プロジェクトによって必要な内容は変わります。

ただし、秘密情報をGit管理に含めないことは必ず意識してください。

AIにコードを書かせる場合でも、APIキーや個人情報をそのまま渡したり、生成されたファイルに秘密情報が混ざったりしないように注意が必要です。

ホットリロードとCursorの内蔵ターミナル

Cursorには内蔵ターミナルがあります。

Webアプリ開発では、内蔵ターミナルで開発サーバーを起動しておくと便利です。

たとえば、Viteなら次のように実行します。

npm run dev

ブラウザでアプリを開き、コードを変更すると自動で反映されます。

このホットリロードの仕組みとCursorのAI機能を組み合わせると、次のような流れで開発できます。

AIにコードを書いてもらう
ブラウザで表示を確認する
エラーが出たらCursorで原因を聞く
修正案を反映する
再度ブラウザで確認する

この繰り返しが、Cursor CLIを使った開発ワークフローの基本になります。

ターミナルからプロジェクトを開き、Cursor内のターミナルで実行し、ブラウザで確認する。この流れがつながると、作業の切り替えがかなりラクになります。

実際に使いやすい依頼文

AIへの依頼は、曖昧にするより具体的にしたほうがうまくいきます。

曖昧な依頼

いい感じのアプリを作って

これだと、AIは何を作ればいいのか判断しづらくなります。

具体的な依頼

HTML、CSS、JavaScriptで、現在時刻を表示するデジタル時計アプリを作ってください。
ファイルは index.html、style.css、script.js に分けてください。
背景は暗め、文字は中央配置、1秒ごとに時刻を更新してください。

このように、使用技術、ファイル構成、見た目、動作条件を伝えると、出力の精度が上がります。

さらに、「新しいライブラリは追加しない」「変更点と確認方法も教えて」といった制約を加えると、より確認しやすい出力になります。

大きな機能は小さく分ける

一度に大きなアプリを作らせると、AIの出力が崩れやすくなります。

たとえば、ECサイトを作る場合でも、いきなり全体を依頼するのではなく、段階的に進めましょう。

ステップ1

商品名、価格、画像を表示する商品カードコンポーネントを作ってください。

ステップ2

商品カードを3つ並べる一覧画面を作ってください。

ステップ3

カートに追加ボタンを押したら、追加済みの商品数が画面上部に表示されるようにしてください。

ステップ4

カート内の商品一覧を表示し、削除できるようにしてください。

このように小さく分けると、確認もしやすく、失敗しても戻しやすくなります。

Cursor CLIで作業開始が早くなっても、AIへの依頼まで雑にすると失敗しやすくなります。作業は速く、依頼は丁寧に進めるのがおすすめです。

AIモデル・エージェント・MCPを使いこなす実践設定

Cursorで使うAIモデルの考え方

Cursorでは、複数のAIモデルを切り替えて使える場合があります。

モデルによって得意分野が違うため、作業内容に応じて使い分けると効率が上がります。

ただし、使えるモデルや料金条件は変わる可能性があります。モデル選択やプランは、使い始める前に最新の内容を確認しておきましょう。

コード生成に向いたモデル

複雑なコード生成やリファクタリングでは、コード理解に強いモデルを選ぶと安定しやすくなります。

特に、複数ファイルをまたぐ変更や設計方針が関わる作業では、精度の高いモデルを選ぶ価値があります。

AgentやComposerに大きな変更を任せる場合は、出力の速さだけでなく、変更内容の妥当性を確認しやすいかも大切です。

短い質問に向いたモデル

ちょっとした文法確認やエラーの意味を聞く程度なら、応答が速いモデルでも十分なことがあります。

たとえば、次のような質問です。

このTypeScriptの型エラーは何が原因ですか？

この正規表現の意味を説明してください。

このCSSが効かない理由を候補で出してください。

このような場面では、速度重視のモデルを使うとテンポよく作業できます。

長いコードを読ませたいときのモデル選び

大きなプロジェクト全体を見てもらいたい場合は、長い文脈を扱えるモデルが便利です。

ただし、プロジェクト全体を毎回読ませると処理が重くなります。

そのため、必要なファイルやフォルダを指定して、AIに渡す情報を絞ることが重要です。

関係のないファイルまで含めると、AIの回答がぼやけることがあります。大きなコードベースほど、「何を読ませるか」を決めることが大切です。

@Filesや@Foldersで文脈を指定する

Cursorでは、AIに参照してほしいファイルやフォルダを指定できます。

たとえば、チャットやComposerで @ を使い、特定のファイルを指定します。

@Files

特定のファイルだけを読ませたいときに使います。

@src/App.tsx このコンポーネントを分割してください。

@Folders

フォルダ全体を参照させたいときに使います。

@src/components コンポーネントの命名規則を統一してください。

@Docs

公式ドキュメントなどを参照させたいときに使います。

@Docs Tailwind CSSの現在の書き方に合わせて修正してください。

@Web

Web上の情報を参照してほしいときに使います。

ライブラリの仕様が変わりやすい場合は、古い知識だけでコードを書かせないために役立ちます。

AIへの情報の渡しすぎに注意する

AIに多くの情報を渡せば、必ず良い結果になるわけではありません。

関係のないファイルまで含めると、回答がぼやけることがあります。

たとえば、CSSだけ直したいのに、プロジェクト全体を読ませる必要はありません。

次のように絞ると、精度が上がりやすくなります。

@src/components/Header.tsx @src/styles/header.css
ヘッダーのレイアウト崩れを修正してください。

必要な情報だけを渡すことで、AIが判断しやすくなります。

これはCursor CLIやAgentを使う場合も同じです。便利だからといって、毎回プロジェクト全体を対象にするより、修正したい範囲を絞ったほうが安全です。

APIキーを設定する場合

Cursorでは、自分のAPIキーを設定してモデルを使える場合があります。

OpenAIやAnthropicなどのAPIキーを設定することで、Cursorのプランとは別にモデルを利用できることがあります。

APIキー運用のメリット

APIキー運用のメリットは、利用状況を自分で管理しやすいことです。

会社やチームですでにAPI契約がある場合は、そのキーを使える可能性があります。

また、モデルを細かく選びたい場合にも向いています。

APIキー運用の注意点

APIキーは従量課金になることが多いため、使った分だけ費用が発生します。

Agentで何度もファイルを読み、コマンドを実行し、修正を繰り返すと、想定以上に利用量が増えることがあります。

APIキーを使う場合は、利用上限や課金状況を確認しながら使う必要があります。

また、APIキーは秘密情報です。コードに直接書いたり、.env をGitに含めたりしないようにしましょう。

MCPとは何か

MCPは、AIと外部ツールやデータソースを連携させるための仕組みです。

CursorでMCPを使うと、AIがファイルシステム、GitHub、データベース、外部サービスなどの情報を参照しやすくなります。

たとえば、データベース構造をAIに理解させたい場合、毎回テーブル定義をコピーして貼り付けるのは手間です。

MCPを使えば、AIが必要な情報へアクセスしやすくなり、より実際の環境に沿った提案を受けやすくなります。

Cursor CLIでも、MCP連携や自動化の文脈で使われることがあります。ただし、最初から必要な機能ではありません。

MCPを使うと何が便利か

MCPの便利な点は、AIに渡す文脈を増やしつつ、作業を効率化できることです。

データベース連携

AIがテーブル構造を理解したうえで、SQLやAPI処理の提案をしやすくなります。

GitHub連携

IssueやPull Requestの情報を見ながら、修正方針を整理しやすくなります。

ファイルシステム連携

プロジェクト内の構造をもとに、必要なファイルを探しやすくなります。

MCP利用時の注意点

MCPは便利ですが、権限管理が重要です。

AIがアクセスできる範囲を広げすぎると、意図しない情報まで参照される可能性があります。

特に、会社のプロジェクト、顧客情報、秘密情報を扱う場合は、連携先と権限を慎重に確認する必要があります。

便利さよりも、安全に使える範囲を決めることが先です。

Cursor CLIを自動化やGitHub Actionsと組み合わせる場合も同じです。便利だからといって、最初から広い権限を渡すのではなく、必要な範囲だけに絞ることが大切です。

Rules for AIで出力を安定させる

Cursorでは、AIに守ってほしいルールを設定できます。

たとえば、次のようなルールです。

- コードを省略せず、実際に動く形で出力する
- 既存の命名規則に合わせる
- 不要なライブラリを追加しない
- 変更前に方針を簡潔に説明する
- コード変更後は確認すべき点を提示する

このようなルールを設定しておくと、AIの出力が安定しやすくなります。

AIに毎回同じ注意点を伝えるより、プロジェクトごとにルールを用意しておくほうが、確認の手間を減らしやすいです。

プロジェクトごとのルール例

Reactプロジェクトなら、次のようなルールが使えます。

# React Project Rules

- コンポーネントは関数コンポーネントで書く
- propsにはTypeScriptの型を定義する
- CSS Modulesを使用する
- 状態管理は既存の設計に合わせる
- テストがある場合は既存の形式に合わせて追加する

Node.jsプロジェクトなら、次のようなルールも考えられます。

# Node.js Project Rules

- 非同期処理は async/await を使う
- エラーハンドリングを省略しない
- 環境変数は process.env から読む
- APIキーをコードに直接書かない
- 既存のディレクトリ構成に合わせる

このようにルールを用意しておくと、AIに任せる範囲が広くなっても、プロジェクトの方針から外れにくくなります。

AIの出力をそのまま信じない

AIが生成したコードは、必ず自分で確認します。

特に確認したいのは次の点です。

実行できるか
型エラーがないか
セキュリティ上の問題がないか
不要な依存関係が追加されていないか
既存の仕様を壊していないか
テストが通るか

AIは強力な補助になりますが、最終的な判断は自分で行う必要があります。

特にAgentは、複数ファイルを一気に変更することがあります。差分確認、Git管理、テスト実行をセットにして使うと安心です。

トラブルシューティングと運用のコツ

cursorコマンドが使えない場合

cursor . を実行してもCursorが起動しない場合、まず確認するのはPATHです。

最初は「Cursorが壊れているのかな」と思うかもしれませんが、実際にはPATH設定やターミナルの再起動忘れが原因のこともあります。

macOSの場合

Cursorを起動し、コマンドパレットから次の項目を実行します。

Shell Command: Install 'cursor' command in PATH

その後、ターミナルを再起動して、もう一度試します。

cursor .

Windowsの場合

環境変数のPathにCursorのbinフォルダが含まれているか確認します。

追加後は、PowerShellやWindows Terminalを再起動しましょう。

Git Bashなど別のシェルで動かない場合は、まずPowerShellやWindows Terminalで動くかを確認すると、問題の切り分けがしやすくなります。

Homebrewでエラーが出る場合

macOSでHomebrewを使っている場合、次のようなコマンドで状態を更新します。

brew update

Cursorのインストールで問題が続く場合は、公式サイトからアプリを直接ダウンロードする方法もあります。

Homebrew側の権限やキャッシュの問題で詰まるより、アプリ本体を入れてからCursor内でShell Commandを設定したほうが早い場合もあります。

ターミナル操作に慣れていない場合は、無理にHomebrewにこだわらず、アプリ本体を入れてから cursor . を使えるようにする流れでも問題ありません。

AIが応答しない場合

CursorのAIが応答しないときは、いくつか原因が考えられます。

ネットワークの問題

会社のVPN、プロキシ、ファイアウォールによって通信が止まっていることがあります。

その場合は、ネットワーク設定やプロキシ設定を確認します。

アカウントやプランの問題

ログイン状態が切れている、利用枠に達している、支払い設定に問題がある、といった可能性があります。

設定画面でアカウント状態を確認しましょう。

モデル側の一時的な問題

選択しているモデルで一時的に応答が遅くなることもあります。

別のモデルに切り替えると動く場合があります。

cursor-agent を使う場合は、ログインや認証が完了しているかも確認しておきましょう。

開発者ツールでエラーを見る

CursorはVS Codeに近い構造を持っているため、開発者ツールからエラーを確認できる場合があります。

メニューから開発者ツールを開き、Consoleに赤いエラーが出ていないか確認します。

APIエラー、タイムアウト、認証エラーなどが表示されることがあります。

AIが応答しない場合も、ネットワーク、認証、モデル側の問題を切り分けるヒントになります。

VS Code拡張機能が動かない場合

CursorはVS Codeベースですが、すべての拡張機能が完全に同じように動くとは限りません。

特に、ネイティブ依存がある拡張機能や、VS Codeの特定バージョンに強く依存する拡張機能では不具合が起こることがあります。

この場合は、次の流れで確認します。

拡張機能を一度無効化する
Cursorを再起動する
拡張機能を再インストールする
拡張機能の設定を見直す
同等の別拡張がないか探す

VS Codeから移行した直後は、設定や拡張機能をそのまま引き継げる反面、環境差による不具合も起こり得ます。

AIの回答が期待と違う場合

AIが的外れな回答をする場合、多くは文脈が足りないか、指示が曖昧です。

ファイルを明示する

@src/App.tsx このファイルの状態管理を整理してください。

目的を明示する

読みやすさを優先して、処理を小さな関数に分けてください。

制約を明示する

新しいライブラリは追加せず、既存のReactとCSSだけで対応してください。

出力形式を明示する

変更点、理由、確認方法の順番で説明してください。

AIには、何を見て、何を目的に、どんな制約で、どう出力してほしいかを伝えると、結果が安定します。

「いい感じにして」だけではなく、対象ファイル、目的、制約をセットで伝えることが大切です。

チャット履歴が長くなりすぎたら整理する

Cursorで長く会話を続けていると、過去の文脈が混ざって回答が不安定になることがあります。

その場合は、新しいチャットに切り替えて、必要なファイルだけを指定し直します。

長い会話を引きずるより、目的ごとにチャットを分けたほうが扱いやすくなります。

Agentに任せる範囲を限定する

Agentに依頼するときは、対象範囲を明確にします。

@src/components 配下だけを対象に、古いprops名を新しいprops名へ変更してください。

このように範囲を絞ることで、関係のないファイルを変更されるリスクを下げられます。

複数ファイルを一気に変更できるのはAgentの強みですが、範囲を広げすぎると確認も大変になります。

実行前の確認を有効にする

Agentがターミナルコマンドを実行する場合、事前確認を求める設定にしておくと安心です。

特に、削除系コマンド、インストール系コマンド、データベース操作系コマンドは注意が必要です。

AIが提案したコマンドでも、意味を確認してから実行しましょう。

コマンドの意味が分からないまま実行するのは危険です。分からない場合は、まず「このコマンドは何をするものですか？」とAIに確認してから進めましょう。

チーム開発でCursorを使う場合

チームでCursorを使うなら、ルールを共有することが重要です。

.cursorrulesをGit管理する

プロジェクトのAIルールを .cursorrules にまとめ、Gitで共有します。

これにより、チームメンバーが同じ方針でAIを使いやすくなります。

AIが生成したコードのレビューを行う

AIが書いたコードも、人が書いたコードと同じようにレビューします。

むしろ、AIが作ったコードほど「それらしく見えるけれど実は間違っている」ことがあります。

そのため、レビューはかなり大切です。

セキュリティルールを決める

外部AIサービスに送ってよい情報、送ってはいけない情報をチームで決めます。

顧客情報、認証情報、未公開の仕様、商用コードなどを扱う場合は特に慎重にしましょう。

Cursor CLIをGitHub Actionsや自動化に組み込む場合も、権限やAPIキーの扱いを必ず確認しておく必要があります。

使い始めにおすすめの流れ

Cursor CLIを使い始めるなら、まずは小さなプロジェクトで流れを試すのが良いです。

いきなり仕事用の大きなプロジェクトで試すより、学習用フォルダや小さな検証用プロジェクトから始めたほうが安心です。

1時間目

Cursorをインストールし、ターミナルで次のコマンドが動くか確認します。

cursor .

動かない場合は、PATH設定とターミナル再起動を確認します。

3時間目

空のフォルダを作り、簡単なHTML/CSS/JavaScriptアプリを作ります。

mkdir first-cursor-app
cd first-cursor-app
cursor .

6時間目

わざとエラーを起こし、ChatやAgentに原因を聞いて修正します。

この段階では、Agentに任せる前に git status を確認する習慣もつけておきましょう。

24時間以内

既存の学習用プロジェクトをCursorで開き、次のように相談します。

このコードを読みやすくする改善案を5つ出してください。

まずは小さく試し、使い方の感覚をつかむのが近道です。

おわりに

Cursor CLIは、通常のCursorとは別物のエディタではありません。

ターミナルからCursorを素早く起動し、開発フローに自然に組み込むための機能です。

cursor . を使えるようにするだけで、プロジェクト作成からAIを使ったコード生成、デバッグ、リファクタリングまでの流れがかなり短くなります。

さらに、cursor-agent を使えば、ターミナル上でAI Agentを使ったり、自動化やスクリプトに組み込んだりする選択肢も出てきます。

とはいえ、最初からすべてを覚える必要はありません。

コードを読んだり、AIチャットで相談したりするだけなら、通常のCursorでも十分です。ターミナルでプロジェクトを移動してから作業を始めることが増えたら、Cursor CLIを試す価値が出てきます。

Cursor本体のAIチャット、インライン編集、Composer、Agentと組み合わせることで、Cursorはただコードを書くためのエディタではなく、開発を一緒に進める作業環境として活用できます。

ただし、AIに任せきりにするのは危険です。

差分確認、Git管理、セキュリティ設定、テスト実行は欠かせません。

まずは小さなフォルダを作り、ターミナルで次のコマンドを入力してみましょう。

cursor .

ここから始めるだけでも、Cursor CLIの便利さを実感しやすいはずです。

よくある質問

Q1. Cursor CLIと通常のCursorは何が違いますか？

A. 通常のCursorは、AI機能を備えたコードエディタ本体です。Cursor CLIは、そのCursorをターミナルから起動したり、ターミナル上でAI Agentを使ったりするための仕組みです。cursor . を使うと、現在のフォルダをCursorで直接開けます。

Q2. Cursor CLIだけでAIにコードを書かせるものですか？

A. 基本的には、CLIでCursorを開き、その後はCursor内のChat、インライン編集、Composer、Agentなどを使ってコード生成や修正を進めます。一方で、cursor-agent を使う場合は、ターミナル上でAI Agentに作業を依頼する使い方もあります。CLIは開発フローの入口として考えると分かりやすいです。