Cursorにどのような脆弱性が報告されているのか
Cursorに報告された主な脆弱性
間接プロンプトインジェクション＋サンドボックスエスケープ
攻撃者が悪意リポジトリのREADMEにプロンプトを埋め込み、Cursorで開くだけでシェルアクセスを奪取。macOSではサンドボックス制限なし。通信はAzure経由で検出困難。
MCP設定ファイル悪用 (CVE-2025-54136)
最初に無害なechoを承認させ、あとでリバースシェルにすり替える。変更確認なしで永続的RCE。共有リポジトリ経由でサプライチェーン攻撃の危険。
自動実行機能とWorkspace Trust問題
Workspace Trustがデフォルト無効で、信頼できないリポジトリの.vscode/tasks.jsonが自動実行。マルウェア仕込みが可能。自動化と干渉するため無効化されている。
cursorignoreバイパス (CVE-2025-64110)
新しいcursorignoreファイルで既存の保護設定を上書きし、保護ファイル（.env等）を悪意エージェントが読み出せる。バージョン1.7.23以下が影響。
間接プロンプトインジェクションとサンドボックスエスケープ
室谷代表取締役シリコンバレーのセキュリティ企業Straikerが見つけたNomShubっていう攻撃連鎖、これ結構やばいんですよね。間接プロンプトインジェクションとサンドボックス回避を組み合わせて、リモートからシェルアクセスを奪う。
テキトー教師DotAI 認定講師たしかに、仕組みが厄介で。攻撃者が悪意のあるリポジトリのREADMEにプロンプトを埋め込んで、Cursorで開くだけで実行される。
ユーザー操作は開くだけ、という。
ユーザー操作は開くだけ、という。
室谷代表取締役macOSの場合、Cursor自体はサンドボックス制限なしで動くから、さらに危険。シェル組み込みコマンドを使って.zshenvを上書きし、ターミナル起動ごとに悪意コードが動く。
テキトー教師DotAI 認定講師しかも通信が全部Azureのインフラを通るから、ネットワークレベルでの検出がほぼ不可能なんですよ。これは設計の穴ですね。
MCP設定ファイルの悪用による永続的RCE
室谷代表取締役もう一つ、MCPoisonって呼ばれる脆弱性。CVE-2025-54136ですね。
MCP設定を一度承認すると、その後コマンドが変更されても再確認なしに実行される。
MCP設定を一度承認すると、その後コマンドが変更されても再確認なしに実行される。
テキトー教師DotAI 認定講師攻撃者は最初に無害なechoだけのMCPを仕込んで承認させ、あとでリバースシェルにすり替える。するとプロジェクトを開くたびにサイレントでRCEが発動する。
室谷代表取締役これ、ビジネス的に見ると共有リポジトリを経由したサプライチェーン攻撃の格好の材料。チームで開発してると、一人が承認したMCPが全員に伝播する可能性がある。
テキトー教師DotAI 認定講師CursorはMCPのキー名だけで信頼を判定してて、コマンドの変更を検証しない。トラストモデルの根本的な欠陥ですよね。
自動実行機能とWorkspace Trustの問題
室谷代表取締役そしてWorkspace Trustがデフォルトで無効な問題。Oasis Securityが指摘してますけど、リポジトリ内の.vscode/tasks.jsonが自動実行される設定になってる。
テキトー教師DotAI 認定講師信頼できないリポジトリを開いただけで、タスクが走ってマルウェアが仕込まれる。本来はWorkspace Trustで確認ダイアログが出るべきなんですが、自動化と干渉するから無効にしてる、と。
室谷代表取締役エンタープライズだとこれが致命傷になる。Cursoとしては「疑わしいリポジトリはWorkspace Trustを有効にして」と言ってるけど、デフォルト無効だと意識しない人がほとんど。
テキトー教師DotAI 認定講師セキュリティガイドラインを出す予定とのことですが、根本的には「自動実行」と「信頼モデル」のバランスをどう取るかですね。
cursorignoreバイパス等の情報漏洩リスク
室谷代表取締役さらにCVE-2025-64110。cursorignoreで保護したはずのファイルを、悪意のあるエージェントが読み出せる脆弱性。
バージョン1.7.23以下が影響。
バージョン1.7.23以下が影響。
テキトー教師DotAI 認定講師新しいcursorignoreファイルを作成することで、既存の保護設定を無効化できる。攻撃者がプロンプトインジェクションを達成すると、.envや秘密鍵を読まれる可能性があります。
室谷代表取締役これはアクセス制御のロジックバグ。階層内で複数のcursorignoreが正しくマージされず、新しいファイルが古いものを上書きしてしまう。
テキトー教師DotAI 認定講師情報漏洩リスクとしては大きい。プロジェクトに機密ファイルを扱うチームは、Cursorのバージョンを最新に保つことと、追加のアクセス制限が必要ですね。
NomShub攻撃連鎖の仕組みと影響
NomShub攻撃連鎖の流れ
- 01READMEに悪意のプロンプトを埋め込むユーザーがリポジトリを開くだけでAIが自動でREADMEを解析し、指示通りに動き出す。特別な操作は不要。
- 02シェルビルトインを悪用したサンドボックス回避Cursorのサンドボックスがシェル内蔵コマンドを保護外だった。macOSのSeatbeltを利用し.zshenvを書き換え、シェル起動ごとに悪意コードが実行される。
- 03リモートトンネル機能による恒久的アクセスCursorのリモートトンネル機能を悪用。AIに指示してデバイスコードを生成させ攻撃者サーバーに送信。攻撃者はコードを使ってGitHub認証を通しトンネルに参加。プロセスが生きている限り認証は失効せず、恒久的なシェルアクセスを得る。
- 04ネットワーク検知が困難全通信がMicrosoft Azure基盤を通るため悪意通信と通常通信が見分けつかない。Cursor自体が署名済み正規バイナリのためファイアウォールも許可する。エンドポイント側での監視が必要。
READMEに仕込まれた悪意のプロンプト
室谷代表取締役今回のNomShub、READMEに悪意のプロンプトを埋め込む間接プロンプトインジェクションなんですよね。ユーザーがリポジトリを開くだけでAIがそれを読んで、指示通りに動き出す。
テキトー教師DotAI 認定講師最初に戸惑うのが「開いただけで感染？」ってところです。実際、特別な操作は一切不要。
AIが自動でREADMEを解析しちゃうから、そこに仕込まれた指示をそのまま実行する。
AIが自動でREADMEを解析しちゃうから、そこに仕込まれた指示をそのまま実行する。
室谷代表取締役日本の現場でも「リポジトリをcloneするだけでやばい」という認識はまだ薄い印象です。シリコンバレーのセキュリティチームはもう警戒してますけどね。
テキトー教師DotAI 認定講師開発者としては「READMEくらい安全だろう」という油断が一番危険です。
シェルビルトインを悪用したサンドボックス回避
室谷代表取締役さらに、Cursorのサンドボックス回避が巧妙で。シェルビルトインが保護範囲外だったんですよね。
テキトー教師DotAI 認定講師たしかに、Cursorはエージェントが直接実行するシェルコマンドには保護をかけていたけど、シェル内蔵のコマンド（cd、exportなど）はスルーしてた。
室谷代表取締役macOSのSeatbeltサンドボックスはホームディレクトリへの書き込みを許してる。それで.zshenvを書き換えて、次にシェルが起動するたびに悪意コードが実行される形に。
テキトー教師DotAI 認定講師つまり、一度仕込まれると、ターミナルを開くたびに感染が再現される。この持続性が厄介ですね。
リモートトンネル機能による恒久的アクセス
室谷代表取締役そして、Cursorのリモートトンネル機能を悪用して、攻撃者が恒久的なシェルアクセスを得る。
テキトー教師DotAI 認定講師具体的には、AIに指示してデバイスコードを生成させ、それを攻撃者のサーバーに送信させる。攻撃者はそのコードを使ってGitHub認証を通し、トンネルに参加する。
室谷代表取締役プロセスが生きている限り、認証は失効しない。トンネルIDとクラスター情報があれば、いつでも接続可能。
テキトー教師DotAI 認定講師開発者のマシンに裏口が永久に開くイメージです。対策を打つまで、何度でも入ってこれる。
ネットワーク検知が困難な理由
室谷代表取締役この攻撃、ネットワークレベルでの検知がほぼ不可能なんですよね。
テキトー教師DotAI 認定講師なぜかというと、全通信がMicrosoft Azure基盤を通る。悪意の通信と通常の通信が見分けつかない。
室谷代表取締役さらにCursor自体が署名済みの正規バイナリ。ファイアウォールも「これはCursorの通信だ」と許可しちゃう。
テキトー教師DotAI 認定講師対策としては、エンドポイント側で異常なファイル操作やシェルコマンドを監視するしかない。ネットワークだけでは守れないんですね。
MCPoison：一度承認すると危険なMCP設定
MCPoison攻撃の手順
- 01初期設定攻撃者が共有リポジトリに無害なMCP設定（例：echo）をコミット
- 02承認被害者が初回プロジェクト開始時にMCPを承認（以降、再確認なし）
- 03書き換え攻撃者がMCP設定をリバースシェルなどの悪意あるコマンドにすり替え
- 04自動実行次回プロジェクト起動時に悪意あるコマンドが自動的に実行される
- 05攻撃成功攻撃者が持続的なシェルを取得し、認証情報やソースコードを窃取
MCPの信頼モデルの穴
テキトー教師DotAI 認定講師MCPって、一度承認するとその後は設定変更があっても再確認が入らないんですよね。
室谷代表取締役そう。Check Point が公開したレポートでも、この「一度信頼したらあとは何も聞かない」っていう設計が狙われてる。
テキトー教師DotAI 認定講師初めてプロジェクトを開いたときに「このMCPを許可しますか？」って出るけど、その後は何の警告もなくなる。
室谷代表取締役つまり最初に無害な echo とかを承認させておいて、後からリバースシェルにすり替えてもバレない。これ、マジで危険なんですよね。
承認後の無警告変更手順
テキトー教師DotAI 認定講師実際の攻撃シナリオとしては、共有リポジトリに安全なMCP設定をコミットしておいて、被害者が承認した後でこっそり書き換える。
室谷代表取締役そうすると、Cursor がプロジェクトを開くたびに悪意のあるコマンドが自動実行される。ユーザーは何も気づかない。
テキトー教師DotAI 認定講師リバースシェルを仕込めば、攻撃者は好きなタイミングでシェルを取得できる。しかもそのセッションは持続する。
室谷代表取締役これ、企業の開発環境でやられると、認証情報やソースコードが全部抜かれる。ROIで考えても攻撃者にとっては美味しい的ですよ。
影響範囲と修正状況
テキトー教師DotAI 認定講師この脆弱性は CVE-2025-54136 として報告されていて、どんなユーザーが影響受けるんですか？
室谷代表取締役MCPを使っているユーザー全員、特にチームでリポジトリ共有している組織がリスク高い。
テキトー教師DotAI 認定講師修正はもうリリースされてる。Cursor 側は2025年7月30日にパッチを出したって聞いてます。
室谷代表取締役でも修正後も、MCP自体の便利さとリスクのバランスは頭に入れておかないと。特に「cursor 脆弱性」を気にしてる開発者は、MCPの信頼モデルを正しく理解しておく必要がありますね。
なぜWorkspace Trustがデフォルトで無効なのか
自動実行リスクと設定ファイル悪用
室谷代表取締役Workspace Trustが無効だと、リポジトリを開いただけで.vscode/tasks.jsonの中身が勝手に動くんですよ。Oasisのレポートで指摘されてましたけど、結構危険ですよね。
テキトー教師DotAI 認定講師そうなんです。初めて触る人は「開いただけなのに実行された」と戸惑うんですが、仕組みとしてはVS Code由来の機能で、Cursorもそれを引き継いでいるんですね。
室谷代表取締役つまり悪意のあるリポジトリを開いた瞬間、設定ファイル経由でマルウェアが走る可能性があると。これがサプライチェーン攻撃につながるとOasisは警告してました。
テキトー教師DotAI 認定講師ええ。だからこそWorkspace Trustの有効化が推奨されるわけです。
ただ、デフォルトで無効になってる理由もあって…それは次の話で。
ただ、デフォルトで無効になってる理由もあって…それは次の話で。
Oasis Securityが指摘した問題
室谷代表取締役Oasisのレポートではっきり書かれてたのは、Workspace Trustが初期設定でオフだと、組織全体が不正アクセスの経路になるってことです。
テキトー教師DotAI 認定講師たしかに。一度無効のまま使い始めると、そのリスクに気づかないまま開発が進んでしまいますからね。
室谷代表取締役Cursor側の説明としては、この機能が一部の自動化と干渉するから初期設定では無効にしてる、と。でもシリコンバレーのセキュリティチームは「信頼できるリポジトリ以外は有効にすべき」と言ってます。
テキトー教師DotAI 認定講師はい。特に企業利用では、セキュリティポリシーとしてWorkspace Trustを強制するかどうかが鍵になります。
Cursor公式の推奨する設定
室谷代表取締役Cursorの公式見解では、怪しいリポジトリを扱うときはWorkspace Trustを有効にするか、基本的なテキストエディタを使えと。
テキトー教師DotAI 認定講師つまり「普段はオフでもいいけど、信用できないコードは隔離しろ」というスタンスですね。近々新しいセキュリティガイドラインも出すそうです。
室谷代表取締役企業のROIで考えると、有効化による手間は微々たるものです。時給換算しても数十秒の確認で大きなリスクを回避できる。
テキトー教師DotAI 認定講師その感覚、大事ですね。有効にすれば毎回確認が出ますが、それに慣れるのが結局は安全です。
Workspace Trust有効化の手順
室谷代表取締役設定自体は簡単で、CursorのSettingsからWorkspace Trustをオンにするだけです。具体的なメニュー位置はバージョンによって異なりますが、検索すればすぐ見つかります。
テキトー教師DotAI 認定講師最初に戸惑うのが「どこにあるの？」ということですが、設定画面の検索機能を使えば一発です。
室谷代表取締役これで不正な自動実行を防止できます。特にチームで共有リポジトリを使うなら、全員に有効化を徹底したほうがいいですね。
テキトー教師DotAI 認定講師そうですね。一度設定してしまえばあとは安心です。
初回だけの手間と考えれば十分価値があります。
初回だけの手間と考えれば十分価値があります。
開発者が今日からできる具体的な対策
まとめ
開発者が今日からできる具体的な対策
- 常に最新バージョンにアップデートする（自動更新推奨）
- Workspace Trust とプライバシーモードを有効にする
- MCP設定を確認し、不審なリポジトリに警戒する
- 企業向け追加セキュリティ機能（SSO、ログ等）を活用する
常に最新バージョンにアップデート
室谷代表取締役脆弱性が公表された翌週にはパッチが出てることがほとんどですね。Cursor も CVE-2025-54135 や MCPoison 関連を 1.3.9 以降で修正してます。
アップデートを後回しにするコスト、時給換算するとバカにならないんですよね。
アップデートを後回しにするコスト、時給換算するとバカにならないんですよね。
テキトー教師DotAI 認定講師たしかに。アップデートが面倒で放置してる人、結構います。
でも自動更新をオンにしてれば通知が来るので、再起動するだけで済みます。
でも自動更新をオンにしてれば通知が来るので、再起動するだけで済みます。
室谷代表取締役うちの現場でも「まだ古いバージョン使ってる」ってエンジニアがいて、すぐアップデートさせました。ROI で考えれば数分の手間でリスクが大幅減るわけです。
Workspace Trust とプライバシーモードの有効化
テキトー教師DotAI 認定講師現場でよく聞くのが、Workspace Trust がデフォルトで無効になってることに気づいてないケースです。Oasis のレポートでも指摘されてましたね。
室谷代表取締役あれは Cursor 側も自動実行との兼ね合いでデフォルト OFF にしてるんですが、結局ユーザーが有効にしないと意味がない。特にチームで共有リポジトリを使うなら、必ず ON にすべきです。
テキトー教師DotAI 認定講師プライバシーモードも一緒に有効にしておくと、コードが学習に使われないので安心です。設定画面からワンクリックです。
室谷代表取締役企業契約なら管理者が一括で強制できるので、最初のオンボーディングで設定してしまうのがいいですよ。
MCP 設定の確認と不審なリポジトリへの警戒
室谷代表取締役MCPoison の攻撃、一度承認するとその後設定が変更されても警告なしで実行される、というのが厄介でした。
テキトー教師DotAI 認定講師プロジェクトの .cursor/rules/mcp.json を開く前に中身を確認する習慣が大事です。初めて開くリポジトリなら特に。
室谷代表取締役承認後に変更があったら再度承認を求める、みたいな仕組みは Cursor も今後改善するでしょうけど、現状ではユーザー側で注意するしかない。
テキトー教師DotAI 認定講師不審なリポジトリはそもそも開かない、というのが根本的な対策ですね。
企業向け追加セキュリティ機能の活用（SSO、ログ等）
室谷代表取締役Enterprise プランなら SSO/SCIM、コンプライアンスログ、MDM デプロイが使えます。開発者一人ひとりに任せるより、組織としてガードレールを敷いた方が効率的です。
テキトー教師DotAI 認定講師ログが残っていれば、万が一脆弱性を踏んだときの追跡ができます。最初は SSO とログの有効化から始めるのが現実的ですね。
室谷代表取締役Cursor は SOC2 Type II 認証も取ってるので、セキュリティ面の信頼性は高い。あとは使う側が機能を使いこなせるかどうかです。
テキトー教師DotAI 認定講師まずは Workspace Trust とプライバシーモード、そして最新版の維持。この3つを守ればほとんどのリスクは回避できると思います。
Cursorのセキュリティへの取り組みと今後の課題
まとめ
Cursorのセキュリティへの取り組み（ポイント）
- 脆弱性報告から5営業日以内に受領通知、重大インシデントはメール連絡。修正は報告から約1ヶ月でリリース（例：NomShubチェーンは3.0で修正）。
- SOC 2 Type II認証取得済み、年1回以上の第三者ペネトレーションテストを実施。trust.cursor.comでサマリー請求可能。
- プライバシーモード（全プラン利用可）でデータ学習をオフにできる。
- 自社開発のセキュリティエージェント（BugBot, Cloud Agent）で内部コードベースを保護。週次3,000件超のPRレビューで200以上の脆弱性を検出。
- 日本の法規制対応：インフラに中国なし、サブプロセッサーに中国企業なし。モデルブロックリストを尊重。
- 日本語版セキュリティページ提供中。今後の課題として、脆弱性情報の日本語開示などローカライズの拡充が期待される。
脆弱性報告プログラムと修正サイクル
室谷代表取締役Cursor、脆弱性の報告受付から対応までのサイクルが明確に定義されてるんですよね。報告から5営業日以内に受領通知、重大インシデントはメールで影響ユーザーに連絡。
テキトー教師DotAI 認定講師たしかに。実際にNomShubのチェーンも報告から1月ほどで3.0で修正されてます。
開発者としては、修正がリリースされたらすぐアップデートするのが基本ですね。
開発者としては、修正がリリースされたらすぐアップデートするのが基本ですね。
室谷代表取締役あとはMCPoisonやCVE-2025-54135もそれぞれ対応済み。MYUUUの現場でも、バージョン管理を徹底してます。
テキトー教師DotAI 認定講師そこが大事です。脆弱性が見つかっても、古いバージョンのまま放置してるケースが結構あるんですよ。
SOC 2認証と年次ペネトレーションテスト
室谷代表取締役SOC 2 Type IIの報告書がリクエストで入手可能で、年1回以上の第三者ペネトレーションテストも実施してる。エンタープライズ案件だとこの辺が通過条件になることも多い。
テキトー教師DotAI 認定講師導入検討の際に、セキュリティ体制を問われるケースは増えてますね。SOC 2の有無で判断材料になる。
室谷代表取締役trust.cursor.comからサマリーも請求できる。コンプライアンス担当に共有しておくといいかも。
テキトー教師DotAI 認定講師あとはプライバシーモードも全プラン利用可で、データ学習をオフにできる。そこもポイントです。
自社コードベース保護のためのセキュリティエージェント
室谷代表取締役自社開発のBugBotとかCloud Agent使って内部のコードベースも守ってる。自分たちで食べてるものは信頼できる、という姿勢ですね。
テキトー教師DotAI 認定講師セキュリティエージェントのプロンプトも公開されてて、PRレビューを自動化してる。3,000件超のPRを週次でレビューして200以上の脆弱性を検出してるとか。
室谷代表取締役あのプロンプト、たった15行の指示で動いてるのがすごい。モデルの進化もあるけど、設計思想が潔い。
テキトー教師DotAI 認定講師現場で真似するのは難しいけど、考え方は参考になります。自社でも似たような仕組みを検討する価値はありますね。
日本の法規制を踏まえた利用のポイント
室谷代表取締役インフラが中国にないこと、サブプロセッサーにも中国企業がいないのは、日本のエンタープライズだと安心材料になります。
テキトー教師DotAI 認定講師あとモデルブロックリストを尊重して、ブロックリストに載ったモデルにはリクエストしない仕組みもある。個人情報の取扱いとか、Privacy Modeで学習を止められる。
室谷代表取締役日本のユーザー向けにセキュリティページの日本語版も用意されてる。そこから各機能の詳細が確認できますし、困ったら公式ドキュメントを読むのが確実ですね。
テキトー教師DotAI 認定講師脆弱性情報の開示も英語だけでなく日本語でも追えると、さらに良いんですけどね。今後のローカライズに期待したいところです。
よくある質問
Q1. この脆弱性はWindows/Mac/Linuxのどれで特に危険ですか？
室谷代表取締役プラットフォーム依存の差はあまり聞かないですね。Cursor自体がElectronベースで動いてる構造上、どのOSでも本質的には同じリスクがあります。
テキトー教師DotAI 認定講師そうなんです。むしろ、開発環境の整い方によって危険度が変わります。
例えば、コンテナを使わずローカルに直接アプリを置いてる人は被害が広がりやすい。
例えば、コンテナを使わずローカルに直接アプリを置いてる人は被害が広がりやすい。
Q2. 信頼できないコードを開かないよう注意する以外に、何か簡単な予防策はありますか？
室谷代表取締役用途ごとに仮想マシンやコンテナで隔離するのが王道ですね。MYUUUの現場でも、外部から取ってきたプロジェクトはDockerでマウントしてから開くようにしてます。
テキトー教師DotAI 認定講師あとは、Cursorの自動更新を常に有効にしておくこと。脆弱性修正は早い段階でパッチが降ってくるので、最新版を保つだけで防げるケースも多いです。
Q3. 他のAIエディタ（GitHub Copilotなど）と比べて、Cursorのセキュリティリスクは大きいのですか？
室谷代表取締役GitHub CopilotもVSCode拡張として似たような攻撃経路はあります。ただ、Cursorは独自のコア機能（MCPなど）を持ってる分、攻撃面は広いかもしれませんね。
テキトー教師DotAI 認定講師リスクの質が少し違うイメージです。Copilotはコード補完のみですが、Cursorはファイル操作やターミナル実行までエージェント的に動くので、そこが狙われやすい。
Q4. もし攻撃を受けた場合、最初に何をすべきですか？
室谷代表取締役まずネットワークを切って、Cursorのプロセスを強制終了。その後、環境変数や認証情報が漏れてないか確認します。
テキトー教師DotAI 認定講師大事なのは、パニックにならないこと。復旧より先に影響範囲を切り分けるのが優先です。
最近の攻撃はRAT化するものも多いので、マシン自体の再イメージングを検討する必要もあります。
最近の攻撃はRAT化するものも多いので、マシン自体の再イメージングを検討する必要もあります。
Q5. 脆弱性の報告から修正までの期間はどれくらいですか？
室谷代表取締役ケースによりますが、重大なものだと数日内にホットフィックスが出ることが多いです。Cursorチームは比較的レスポンスが早い印象です。
テキトー教師DotAI 認定講師ただ、ユーザーがアップデートを適用するまでにタイムラグがあるので、そこが課題ですね。自動更新を即座に受ける設定にしておくと安心です。
まとめ
室谷代表取締役Cursorの脆弱性、特にNomShubやMCPoisonのような攻撃連鎖は、エージェント型エディタの新しいリスクを象徴してますね。
テキトー教師DotAI 認定講師そうですね。従来のIDEでは考えられなかった攻撃経路が現実になっていて、開発者側も「信頼できるコードだけを開く」という基本に立ち返る必要があります。
室谷代表取締役一番の対策は、Workspace Trustを有効にして、未知のプロジェクトを開くときは常に制限モードで起動すること。あと、定期的なアップデート。
テキトー教師DotAI 認定講師現場でよく聞くのは「面倒だから全部許可しちゃう」という声ですが、それが一番危ない。ワンクリックの承認が取り返しのつかない被害につながることを意識してほしいです。
室谷代表取締役これからも新しい攻撃手法は出てくるでしょう。でも、基本を押さえていれば大抵は防げます。
まずは今日、Cursorの設定を見直すところから始めましょう。
まずは今日、Cursorの設定を見直すところから始めましょう。
