Cursor 日本語化と設定カスタマイズ入門

Cursorの日本語化で最初に知っておくこと

UI翻訳とAI返答言語の違い

Cursorで最初につまずきやすいのは、画面の表示言語と、AIが返す説明の言語を同じ設定だと思ってしまう点です。
実際にはここは分かれていて、メニューや設定画面の日本語化はUI側の話、チャットやコード説明を日本語で返してもらうのはAI側の話です。
筆者の体験や一部ユーザーの報告では、初回起動時にLanguage for AIの選択が提示されることがあり、その場で日本語を選ぶとAIの返答傾向が日本語寄りになる場合がありますが、これはあくまで筆者や一部報告に基づく挙動で、環境やバージョンによって表示されないこともあります。
公式の挙動が確実に必要な場合は docs.cursor.com や公式サポートでの確認を推奨します。

比較の要点を先に並べると、見ているものは次の3つです。

• UI日本語化は、メニュー、設定画面、拡張機能ビューなどを読みやすくするための設定です
• AI返答日本語化は、チャット欄やコード解説を日本語で受け取るための設定です
• コメントやコードの言語運用は、コードコメントを英語に寄せるか、日本語の説明をどこまで残すかといった作業ルールです

この3つを混ぜると、「日本語設定にしたのに英語が出る」「AIは日本語なのに設定画面が読めない」といったズレが起きます。
逆に分けて考えると、何を変えればどこが直るのかが見えてきます。

なぜVS Codeの言語パックを使うのか

CursorのUI日本語化で定番になっているのが、Visual Studio Code向けのJapanese Language Pack for Visual Studio Codeを使う方法です。
理由は単純で、CursorがVS Codeベースのエディタだからです。
操作感や拡張機能の考え方が近く、日本語化もその流れに乗るのがいちばん自然です。

具体的には、拡張機能ビューでJapanese Language Pack for Visual Studio Codeを入れ、コマンドパレットからConfigure Display Languageを実行して、日本語ロケールを選びます。
その後にChange Language and RestartまたはRestartを実行すると、表示言語が切り替わります。
なお、以下の手順は VS Code の言語パック運用に基づく手順であり、Cursor の公式ドキュメント上に同一の専用ページが見つからない（または見つけにくい）場合があります。
手順の確証が必要な場合は docs.cursor.com や公式サポートで動作確認をしてください。

全部が日本語になるわけではない

日本語化が反映されても、画面内の文字が100％すべて日本語に揃うとは限りません。
ここで注意したいのは、表示言語の切替手順（言語パックの導入 → Configure Display Language → 再起動）は VS Code 側の言語パック運用に基づく流れであり、実務上は Cursor でも有効なケースが多い一方で、Cursor の公式ドキュメントに同様の専用ページが明確に存在しない、または見つけにくい場合がある点です。
手順の確証が必要な場合は。

AIの返答言語も、設定を日本語にしただけで常に固定されるわけではありません。
技術用語やライブラリ名、コードブロックの周辺では英語が混ざることがあります。
実務ではこの混在をむしろ活かしたほうが自然で、説明文は日本語、コードコメントや識別子は英語寄り、という運用のほうが読み返しや共同作業で崩れにくくなります。
チームで使うなら、コメント言語を日本語か英語のどちらに揃えるかまで含めてルール化したほうが、レビュー時のブレを減らせます。

この段階で見えてくるのは、日本語化のゴールが「全部の文字を日本語に置き換えること」ではなく、「自分が迷わず設定できて、AIとのやり取りも読みやすい状態を作ること」だという点です。
次の設定では、その前提の上にAIの返答言語やRulesの方向性を重ねていくと、日常の開発フローにきれいに収まります。
Cursor Docs Rulesのような発展的な機能に進む前でも、この土台が整っているだけで操作ミスはぐっと減ります。

Rules ｜ Cursor Docs

Configure persistent instructions with Project, Team, and User Rules, plus AGENTS.md. Learn best practices for effective

cursor.com

Cursorを日本語化する手順

拡張機能ビューを開く

ここからは、実際にCursorの表示言語を日本語へ切り替えていきます。
作業時間の目安は1〜5分ほどで、流れとしては「言語パックを入れる」「表示言語を切り替える」「再起動して反映を見る」の3段階です。
CursorはVS Codeベースなので、拡張機能まわりの操作もほぼ同じ感覚で進みます。

最初に、左側サイドバーの拡張機能アイコンをクリックするか、ショートカットで拡張機能ビューを開きます。
Macは Cmd+Shift+X、Windowsは Ctrl+Shift+X です。
もしサイドバーが閉じていても、このショートカットなら直接開けます。

実際に使ってみると、このショートカットを覚えておくと日本語化だけでなく、その後のテーマ追加や便利拡張の導入でもそのまま使えます。
英語UIの段階では、左側のアイコンだけで目的の画面を探すより、ショートカットで一気に開いたほうが迷いません。

言語パックを検索・インストール

拡張機能ビューが開いたら、上部の検索ボックスに Japanese Language Pack for Visual Studio Code と入力します。
候補の中にMicrosoft系の日本語言語パックが表示されたら、それを選んで Install を押します。
拡張IDは MS-CEINTL.vscode-language-pack-ja です。

正式名称で検索すると見つけやすいですが、途中までの Japanese Language Pack でも候補に出ることが多いです。
英語UIのままだと一覧の情報量が多く見えるので、まず検索ボックスに正式名をそのまま貼り付ける進め方だと止まりにくい設計です。

インストールが終わると、言語切替を促すメッセージや、関連する操作候補が出ることがあります。
その場で切り替えに進める場合もありますが、手順として覚えやすいのは次のCommand Paletteから進む方法です。
画面の文言が多少違っていても、操作の軸がぶれません。

表示言語を日本語に切替

言語パックを入れたら、Command Paletteを開きます。
Macは Cmd+Shift+P、Windowsは Ctrl+Shift+P です。
メニューからたどるなら View > Command Palette でも開けます。

開いた検索欄で display と打ち始めると、候補に Configure Display Language が浮かび上がってくることが多いです。
実際、この方法がいちばん迷いません。
コマンド名を丸ごと覚えていなくても、display の数文字で絞り込めるので、英語UIでも進めやすい流れです。

Configure Display Language を選ぶと、インストール済みの表示言語一覧が出ます。
ここで 日本語 または ja を選択します。
表示が Japanese (ja) になっている場合もあります。

この段階でつまずきやすいのは、言語パックを入れる前にコマンドだけ実行してしまうケースです。
その場合は日本語候補が一覧に出ません。
ja が見当たらないときは、前の手順に戻って言語パックが入っているかを見ると整理しやすくなります。

再起動と反映確認

日本語または ja を選ぶと、Restart や Change Language and Restart といったボタンが表示されます。
これを押してCursorを再起動すると、表示言語が反映されます。
再起動は数十秒で終わることが多く、作業の流れを大きく止めずに済みます。

反映確認では、再起動後に設定画面の見出しが日本語になっているかを見ると判断しやすいのが利点です。
たとえば Settings を開いたとき、項目名や見出しが日本語表記に切り替わっていれば成功です。
筆者もここを最初の確認ポイントにしています。
メニューやサイドバーより、設定画面のほうが変化を見分けやすいんですよね。

もし再起動後も英語のままなら、まず確認したいのは次の2点です。
1つは言語パックがインストール済みになっているか、もう1つは再起動を実行したかです。
日本語化の手順そのものは短いですが、この2点が抜けると表示が変わりません。

なお、日本語化が反映されても、一部のCursor独自UIやエラーメッセージは英語のまま残ることがあります。
ここは失敗ではなく、翻訳対象の範囲によるものとして見ると状況を把握しやすくなります。
導入まわりの全体像はCursor Docs Quickstartも合わせて見ると、初期設定の流れがつかみやすくなります。

Quickstart ｜ Cursor Docs

Go from install to your first useful change in Cursor. Sign in, ask Cursor to explain your codebase, make a small edit,

cursor.com

うまく見つからない時の検索語リスト

バージョンによって文言が少し変わることがあるので、画面上の表記どおりに探しても見つからない場面があります。
そういうときは、完全一致よりも検索駆動で探したほうが早いです。
Command Paletteでも拡張機能検索でも、次の語から入ると候補を絞り込みやすくなります。

拡張機能ビューで使う検索語は、Japanese Language Pack for Visual Studio Code、Japanese Language Pack、language pack ja、vscode-language-pack-ja あたりが有効です。
正式名称で出ないときでも、拡張ID寄りの語にすると候補が見えることがあります。

Command Paletteでは、display、language、Configure Display Language、表示言語 の順で試すと見つけやすいのが利点です。
英語UIでは display が特に強く、数文字入れただけで候補が前に出てくることがあります。
日本語UI寄りの表記が混ざっている場合は 表示言語 でも拾えます。

検索語を短く切って探す発想を持っておくと、UI表記が少し違っていても先に進めます。
Cursor Changelogのように更新が継続しているツールでは、画面の文言が固定ではない前提で、検索欄に display や language を入れて目的のコマンドを呼び出す操作を覚えておくと、その後の設定変更でも役立ちます。

Changelog · Cursor

New updates and improvements.

cursor.com

AIの返答を日本語中心にする設定と使い分け

Language for AIとは何か

UIを日本語に切り替えたあとでも、チャット欄の返答だけ英語のまま残ることがあります。
ここで切り分けたいのが、画面表示の言語とAIが返す言語は別物だという点です。
前者はメニューや設定画面の翻訳で、後者はCursor内のAIがどの言語で説明文を書くかという挙動です。

その後者に関わる設定として見かけるのが Language for AI です。
これはAIの返答言語の傾向を決める項目であり、UIそのものを日本語化するスイッチではありません。
ここを日本語寄りにしておくと、コードの説明、修正理由、提案文を日本語で返す場面が増えます。
一方で、メニュー名や設定ラベルが日本語になるわけではないので、表示言語の切替と混同すると途中で話が噛み合わなくなります。

この項目はバージョンによって表記が揺れることがあります。
Language for AI のほかに、Chat Language、Preferred language のような名前で近い意味の設定が置かれていることもあります。
設定画面で見つからないときは、完全一致で探すより language、chat、AI、reply、preference といった語で検索したほうが早く辿れます。
Cursor Changelogを見ても更新頻度は高く、設定名や配置が固定ではない前提で探すほうが実務では止まりません。

会話プロンプトでの明示指示テンプレート

設定を日本語寄りにしていても、会話の文脈や直前の入力内容によっては英語で返ることがあります。
そこで安定しやすい運用として効くのが、会話の最初に言語方針を明示するやり方です。
単に設定に任せるより、毎回のスレッド冒頭で「どう返してほしいか」を書いたほうが、説明の言語がぶれにくくなります。

たとえば最初の一文を、次のように固定しておくと扱いやすくなります。

「以後の説明は日本語でお願いします。コードコメントと技術用語は英語を優先してください。」

この形にしておくと、本文の理解しやすさとコードの可搬性を両立できます。
説明まで英語だと初心者には負荷が高く、逆にコメントや用語まで日本語に寄せると検索時に詰まりやすくなるからです。
たとえば dependency injection を「依存性注入」とだけ書くより、英語のまま残したほうが検索結果や公式ドキュメントと結びつきます。
null pointer exception のようなエラーメッセージ周辺も同じで、日本語訳だけにすると調査の入口が狭くなります。

実際の使い分けは、次のようなイメージです。関数の意図や処理の流れの説明は日本語で受け取り、コード内コメントは英語で揃えます。

// Validate user input before API call
function submitForm(data: FormData) {
 // ...
}

このコードに対するAIの説明は「この関数はAPI呼び出し前に入力値を検証する前提で組まれています」と日本語で返してもらい、コメント自体は英語のままにします。
筆者はこの「説明は日本語、コードコメントは英語」を最初のルールとして固定してから、レビュー時の認識ズレが目に見えて減りました。
説明文は日本語なので意図の共有が速く、コメントは英語なのでリポジトリ全体の統一感が崩れません。
筆者の体験では、この「説明は日本語、コードコメントは英語」を最初のルールとして固定してから、レビュー時の認識ズレが目に見えて減りました。
（一部ユーザー報告に基づく体験談です。
環境やバージョンにより挙動が異なることがあります。
）

Rulesで既定の指示を共通化する考え方

毎回同じ言語指示を書くのが面倒なら、Cursorの Rules で既定の指示としてまとめる考え方があります。
たとえば「説明は日本語」「コードコメントは英語」「技術用語は原語優先」といった方針を共通ルールにしておけば、新しい会話でも土台が揃います。
個人利用でも便利ですが、複数人で触るプロジェクトではさらに効きます。
誰かは日本語コメント、誰かは英語コメント、AIの返答も会話ごとにバラバラ、という状態だとレビューと保守のコストが積み上がるからです。

ここに言語方針を書いておくと、毎回の冒頭プロンプトを短くできます。
たとえば「Explain in Japanese. Keep code comments in English. Prefer English for technical terms and API names.」のようなルールです。
英語で書くのは、ルール文そのものを短く明快に保ちやすいためです。

なお、RulesのUI上の位置や名称はバージョンによって動くことがあります。
設定項目が見当たらない場合でも、考え方自体は同じです。
会話ごとに都度指示するか、共通ルールに寄せるかの違いであって、狙いは「返答の言語と表記ルールを先に固定する」ことにあります。

なぜ用語やコメントは英語が安定しやすいのか

技術分野では、日本語に訳し切らないほうが安定するものが少なくありません。
理由は単純で、公式ドキュメント、エラーメッセージ、ライブラリ名、検索インデックスの多くが英語基準で作られているからです。
Cursorに限らず、VS CodeやGitHub、各種フレームワークの資料も英語の語彙を軸に組み立てられています。

たとえば commit, rebase, hook, schema, middleware といった言葉は、日本語訳を当てても文脈ごとの意味の揺れが残ります。
AIに対して「全部日本語で」と求めると、説明は読めても検索語として弱くなり、チーム内でも表記ゆれが起きます。
middleware を「ミドルウェア」と書く人もいれば「中間処理」と言う人も出てくる、という具合です。
コメントや識別子まで日本語に寄せると、英語ベースのOSS文化と接続しにくくなる場面も増えます。

そのため実務では、説明文は日本語、技術用語とコードコメントは英語 という分け方が収まりやすいのが利点です。
可読性と検索性のバランスが取りやすく、AIへの指示も短く済みます。
レビューで読む側は日本語の説明で意図をつかめて、詰まった用語はそのまま英語で検索できます。
この線引きがあるだけで、「日本語で返してほしいのに、どこまで日本語化するのか」という迷いが減ります。

Language for AIは便利ですが、それだけで全要素をきれいに統一する機能ではありません。
返答の主言語を日本語に寄せつつ、技術用語とコメントは英語に残す。
この使い分けまで含めて設計すると、UI日本語化のあとに残りがちな「AIだけ英語で返ってきて疲れる」という違和感が解けていきます。

最初にやっておきたい設定カスタマイズ

初心者向け：まず入れる3つ

日本語化の次に手を入れるなら、最初は設定を増やしすぎないほうが流れが整います。
CursorはVS Code系の設定や拡張機能を引き継げる前提で触れるので、初回の Import を使って移すこともできますし、あとから必要なものだけ再設定する形でも十分です。
土台として効くのは、Auto Save、Format on Save、タブ幅とインデントの統一の3つです。

Auto Save を有効にすると、保存し忘れたままターミナルで実行して「直したはずのコードが反映されていない」という初歩的な詰まり方が減ります。
とくに Cursor へ移行した直後は、エディタ操作そのものよりAIとの往復に意識が向きやすいので、保存を手動運用に残すメリットがほとんどありません。
会話で提案された修正をそのまま試す流れとも相性がよく、編集と実行の往復が途切れません。

Format on Save も早めに入れておくと効果が出ます。
保存のたびに整形が走るだけですが、インデント、改行、クォート、末尾カンマの揺れがその場で消えるので、あとでまとめて直す手間を抱えずに済みます。
私自身、これを有効にした直後から PR 差分のノイズが目に見えて減り、レビューで見るべき点が「見た目の揃え方」から「処理の意図」に戻りました。
レビュー時間が短くなったと体感した設定のひとつです。

タブ幅とインデントも、最初に決めてしまったほうが後で困りません。
たとえば 2 スペースに統一しておけば、JavaScript や TypeScript、JSON、YAML まわりで揺れが出にくく、AIが生成したコードを貼ったときも整形結果が安定します。
ここが未設定のままだと、あるファイルはタブ、別のファイルはスペースという状態になり、フォーマッタ導入後に差分が一気に出ます。
個人開発でも見づらさが残りますし、チーム開発ではレビューの邪魔になります。

この3つは派手ではありませんが、入力、保存、整形の基本動作を先に固定する設定です。
日本語UIになって設定画面を追いやすくなった段階でここまで揃えると、その後に入れるショートカットやRulesの効果も乗りやすくなります。

すぐ効く効率化

基本設定の次は、毎日何度も触る操作だけを先に短縮すると、操作の迷いが減ります。
見直し対象としてわかりやすいのは、Command Palette、拡張機能ビュー、エディタの基本操作、統合ターミナルです。
VS Codeから移ってきた人なら既に体が覚えていることもありますが、CursorではAI関連の操作が増えるぶん、基礎ショートカットを再確認しておく意味があります。

コマンド実行の入口になる Command Palette は、macOS なら Cmd+Shift+P、Windows なら Ctrl+Shift+P です。
拡張機能ビューは macOS で Cmd+Shift+X、Windows で Ctrl+Shift+X が基準になります。
設定名を正確に覚えていなくても、ここから「format」「terminal」「display」などで絞り込めるので、メニューを探し回る時間が消えます。
Cursorのキーバインド全体はCursor Docs Quickstartや公式ドキュメントのキーボード設定ページの流れに沿って確認できますが、最初の段階では全部を覚える必要はありません。
毎日使う入口だけで十分です。

統合ターミナルも、別アプリ感覚で扱わず、エディタの一部として呼び出せる状態にしておくと作業が締まります。
ショートカットを押して開く動きが自然になると、ファイル編集、実行、ログ確認の往復が1つの画面で閉じます。
1日目は意識してショートカットだけで開くように反復すると、手が勝手に動く段階まで早く持っていけます。
メニューから毎回開いていると、この差は積み上がります。

表示まわりでは、ミニマップを残すか消すかも序盤で決めておくと画面の情報量が落ち着きます。
長いファイルを俯瞰したい人には便利ですが、ノートPCの横幅が限られる環境ではコード本文の表示幅を削ります。
日本語化直後は設定項目の意味を追いやすいので、この手の好み設定も一度まとめて触っておくと、あとで散らかりません。
表示まわりでは、ミニマップを残すか消すかも序盤で決めておくと画面の情報量が落ち着きます。
長いファイルを俯瞰したい人には便利ですが、ノートPCの横幅が限られる環境ではコード本文の表示幅を優先してください。
拡張機能は最小構成から始めるのが無難です。
フォーマッタ、リンタ、言語サポートの3系統があれば、多くのプロジェクトで十分に出発できます。

AIまわりでは、初期モデルの選択と返答スタイルのテンプレート化も早めに整えておくと会話のブレが減ります。
たとえば「説明は日本語、コードコメントは英語、技術用語は原語優先」のような方針を Rules に寄せておけば、毎回の冒頭指示を短くできます。
Cursor Docs Rulesで案内されている通り、Rules は単なるメモではなく、会話の初期条件を固定する場所として使えます。
モデル選択も、速度重視で試す場面と、説明の丁寧さを優先する場面を分けておくと、どの会話で何を期待するかが曖昧になりません。

チーム向け：コメント言語と共通設定の整備

個人利用では多少の表記ゆれが残っても回せますが、チームに入った瞬間に効いてくるのがコメント言語と共通設定です。
前のセクションで触れた通り、説明は日本語、コードコメントは英語という分け方は収まりがよく、この方針は個人設定ではなくチームルールにしたほうが運用が安定します。
誰かは日本語コメント、誰かは英語コメント、AIは会話ごとに別の言い回し、という状態になると、コードレビューで判断したい論点が埋もれます。

コメント言語の統一は、読み手の母語よりも、リポジトリ全体で検索できるかどうかに効きます。
関数名、クラス名、API名が英語で並んでいる場所に日本語コメントが混ざると、意図の説明と仕様上のキーワードが分断されます。
逆に、コメントを英語で揃えたうえで、PR説明やAIの補足を日本語に寄せると、レビュー中の理解速度と検索性の両方を保てます。

formatter と linter の設定共有も、チームでは避けて通れません。
各自がローカルで好きな整形設定を持っていると、保存のたびに差分が揺れます。
だからこそ、Format on Save を個人の快適設定で終わらせず、プロジェクト側の整形ルールとセットで見る必要があります。
私の感覚では、ここが揃っていないチームは、コードの品質以前に差分の読みづらさで消耗します。
保存しただけで余計な変更が出ない状態にしておくと、レビューで会話すべき箇所が自然に絞られます。

Rules も個人専用に閉じず、チームの共通テンプレートとして持つと効果が出ます。
たとえば「日本語で要点を説明する」「コードコメントは英語」「提案コードは既存の formatter/linter 設定に従う」「曖昧な命名は避ける」といった内容です。
これを各自が毎回書く運用にすると、少しずつ文面がズレていきます。
共通化しておけば、AIの返答の粒度や語彙が揃い、レビューコメントにも一貫性が出ます。

CursorはVS Codeからの移行文脈で入る人が多いので、既存の keybindings や settings を引き継げること自体は大きな利点です。
ただ、チーム運用では「移せること」と「揃えること」は別です。
個人の快適さを残しつつ、コメント言語、整形、警告基準、AIへの既定指示だけは共通化する。
その線引きができると、エディタの好みは違っても、リポジトリに残る成果物の見た目と判断基準は揃います。

日本語化できない・反映されないときの対処法

まず疑う3点：未インストール／未切替／未再起動

日本語化が反映されないときは、設定画面をあちこち探すより、最初に3点だけ絞って見たほうが早いです。
多くはここで止まっています。
VS Code系の表示言語切り替えは、言語パックを入れる、表示言語を切り替える、再起動する、の3段階で成立しているので、どれか1つ抜けると中途半端に英語が残ります。

チェックする順番は次の3つです。

• Japanese Language Pack for Visual Studio Codeがインストール済みか確認する
• Configure Display Languageで表示言語がJapanesejaに切り替わっているか確認する
• Change Language and Restartまたは再起動を実行したか

1つ目は、拡張機能一覧に日本語パックが入り、有効化されているかを見るだけです。
2つ目は、コマンドパレットから display と打ってConfigure Display Languageを開き、選択中の言語が日本語になっているかを見ます。
検索語が日本語だと候補に出にくい場面もあるので、display、language、locale のような英語語句で探すと到達が早いです。
3つ目は見落としやすく、切り替えたつもりでも再起動前の画面をそのまま見ていることがあります。
Microsoftのロケール関連情報でも、表示言語の変更は再起動前提の流れになっています。

ここで混同しやすいのが、UIの日本語化と、AIの返答を日本語にする設定は別物だという点です。
メニューや設定画面が英語のままでも、AIだけ日本語で返してくることがありますし、その逆も起こります。
前のセクションで触れた設定が効いているかどうかと、表示言語が切り替わっているかどうかは、分けて見たほうが詰まりません。

仕様として英語のまま残る領域

再起動後も一部の英語が残ると失敗に見えますが、そこは不具合ではなく仕様として残る領域があります。
特にCursor独自のUIや、比較的新しい機能、拡張機能側の文言は英語のまま出ることがあります。
VS Code本体に近いメニューや基本設定は日本語化されても、独自パネルやAI関連の細かなラベルだけ英語、という状態は珍しくありません。

これは言語パックが効いていないというより、翻訳対象の範囲やバージョンごとの差です。
実際、私も移行直後に設定画面の大半は日本語になった一方で、Cursor固有の項目だけ英語で残りました。
その時点で切り分けができていると、余計な再設定に走らずに済みます。

エラーメッセージも同様で、日本語化後でも英語のまま表示されることがあります。
開発ツールでは、エラー本文が実行環境や拡張機能、言語サーバー側から返ってくるためです。
ここはむしろ英語のままのほうが検索しやすい場面もあります。
UIが日本語なのにエラーだけ英語でも、それ自体は異常ではありません。

文字化け・表示崩れの見直しポイント

日本語化そのものはできているのに、文字が欠ける、四角い箱で出る、幅が崩れる、といった症状はフォントまわりを疑うのが近道です。
エディタ本文、ファイルの文字コード、Terminal の3か所で見直すと、原因が見えやすくなります。

まずエディタ本文では、日本語グリフをきちんと持つフォントを使っているかが効きます。
英字前提の等幅フォントだと、コメントや設定項目の日本語が不自然な幅になったり、読点や記号の位置が落ち着かなかったりします。
Noto Sans Mono CJKやSource Han系のように、日本語を含むフォントへ切り替えると収まりが整います。

次に見るのがファイルの文字コードです。
ソースや設定ファイルが UTF-8 以外で保存されていると、本文は読めるのに一部だけ文字化けすることがあります。
特に古いプロジェクトや外部ツール経由で作られたファイルでは、表示言語ではなく文字コードが原因になっていることがあります。

見落としやすいのが Terminal です。
Windows環境で統合ターミナルの日本語が□で並んだことがありましたが、等幅の日本語対応フォントに切り替えたらその場で解消しました。
UIは日本語化できているのにターミナルだけ崩れるなら、まず Terminal 用フォントとロケール設定を見るほうが筋がいいです。
コマンドの出力、CLI ツール、Git のメッセージはエディタ本体とは別経路で描画されるので、UI設定だけでは揃いません。

切り分けと再インストール手順のヒント

3点確認と表示まわりの見直しをしても直らないときは、設定を増やすより切り分けに寄せたほうが進みます。
最初に試したいのは、日本語言語パックの再インストールです。
いったん削除して入れ直し、表示言語を再選択すると、途中で壊れた状態を引きずらずに済みます。

その次に有効なのが、別プロファイルで起動するか、一時的に拡張機能を絞る方法です。
拡張機能同士の干渉で表示が乱れることがあり、普段の環境のまま原因を追うと対象が広がります。
素の状態に近いプロファイルで日本語表示になるなら、本体ではなく追加要素に原因が寄っています。
逆に、最小構成でも同じなら、言語パックの適用かアプリ側の状態を疑うほうが自然です。

Cursor Changelogを見て、直近の更新で表示周りに変更が入っていないかを当たるのも有効です。
日本語化はVS Codeの仕組みに乗っていても、Cursor独自UIの翻訳反映タイミングはリリースごとに揺れます。
アップデート後に急に一部だけ英語へ戻った場合、こちらの設定ミスではなく更新側の変化として読んだほうが筋が通ることがあります。

検索で情報が見つからないときは、日本語で「反映されない」と打つより、display language not applied、locale、language pack、terminal font のように英語で探したほうが、近い事例に届きやすいのが利点です。
CursorはVS Code由来の部品を多く持つので、Cursor固有の不具合に見えても、VS Code側の対処で解決することがあります。

日本語化後におすすめの使い方

はじめての一問一答：3行要約から始める

日本語化を終えた直後は、いきなり大きな生成タスクを投げるより、短時間で答え合わせできる小さな問いから入ると感触をつかみやすくなります。
最初の一問として相性がいいのは、「このファイルの役割を日本語で3行で説明」です。
長い説明を求めないぶん、返答の質を判断しやすく、読み手側も負荷が軽く済みます。

たとえば、開いているTypeScriptやPythonのファイルに対して、次のように聞くだけで十分です。

「このファイルの役割を日本語で3行で説明してください。専門用語は必要最小限にしてください。」

この聞き方の良いところは、コード全体を把握していなくても、入口として機能することです。
エントリーポイントなのか、API呼び出しなのか、UI描画なのかが3行に圧縮されるだけで、次にどこを見るべきかが見えてきます。
既存コードの読解で詰まりやすいのは、1行ごとの意味ではなく、ファイル単位の役割が掴めない状態だからです。

私自身、日本語化した直後の最初の30分で、関数 foo の処理を日本語で要約し、そのあと不要分岐の削除案を出してもらい、仕上げに英語コメントを足す、という三段階を試しました。
いきなり実装を書かせるより、理解してから小さく整える流れのほうが頭に入りやすく、コードを読む速度が一段上がった感覚がありました。

ここでのコツは、説明対象を広げすぎないことです。
プロジェクト全体ではなく、まずは1ファイル、1関数、1クラスに絞ると返答の精度が安定します。
基本操作とも相性がよく、開いている文脈に対して質問するだけでも、最初の実利用には十分つながります。

軽い編集依頼：安全なリファクタ提案

日本語での説明に慣れたら、次は壊しにくい軽い編集依頼へ進むと流れが自然です。
初心者が最初に試す変更としては、挙動を大きく変えないものが向いています。
たとえば、変数名や関数名の見直し、Docstring の追加、重複した条件分岐の整理案あたりです。

既存コードの解説と相性がいい依頼文は、次のような形です。

「この関数が何をしているか日本語で要約したうえで、名前が曖昧ならリネーム案を3つ出してください。処理内容は変えないでください。」

これなら、説明と改善案が一度に返ってきます。
foo や dataProc のような名前が残っているコードでは、リネーム候補を見るだけでも設計意図の理解が進みます。
名前を変える理由まで書かせると、提案の良し悪しも判断しやすくなります。

Docstring を足したい場面なら、こう聞くと扱いやすいのが利点です。

「この関数にDocstringを追加してください。説明は日本語で、引数名と戻り値名はコードに合わせてください。実装は変更しないでください。」

この依頼は、既存コードを壊さず情報だけを足せるので、最初の編集対象として安定しています。
特に引数が複数ある関数や、副作用を持つ処理では、Docstring があるだけで再読コストが下がります。

不要分岐の整理を頼むときも、いきなり「リファクタしてください」と投げるより、提案止まりにしたほうが安全です。

「この関数で不要に見える分岐があれば、日本語で理由を説明し、削除案を提示してください。まだコードは書き換えず、提案だけにしてください。」

この段階を踏むと、AIが勝手に広い変更を始めるのを防げます。
筆者が最初の30分で試した三段階でも、要約の次にこの“提案だけ出させる”工程を挟んだことで、変更の意図を自分で確認できました。
理解せずに置換するより、どの分岐が死んでいるのかを日本語で読んでから触るほうが、修正の納得感が高まります。

もう一歩進めるなら、軽い編集依頼を毎回ほぼ同じ型で使い回すと安定します。たとえば次の3つは、そのままテンプレとして使えます。

1. 「このファイルの目的を日本語で要約し、主要な関数を役割ごとに整理してください。」
2. 「この関数の名前が曖昧なら、処理内容に沿ったリネーム案を3つ出してください。理由も日本語で添えてください。」
3. 「既存コードは変えずに、英語のDocstringと最小限のコードコメント案だけ作ってください。」

設定をさらに詰める段階では、Cursor Docs Rulesのような仕組みで、コメント規約や説明言語を揃える運用にもつなげられます。
ただ、最初の実利用では会話の中で明示したほうが、どこまで指示が効いたかを掴みやすい場面が多いです。

日本語×英語の使い分け練習プロンプト

実務では、説明は日本語、コードコメントは英語という分担が収まりやすいことがよくあります。
読む人の理解は日本語で助けつつ、コードベースのコメントはGitHubやチーム運用に合わせて英語に寄せる、という形です。
日本語化したCursorは、この切り替え練習に向いています。

たとえば、既存コードに対して最初の一往復はこうです。

「この関数を日本語で説明してください。そのうえで、処理内容が伝わる英語コメントを関数の上に2行だけ提案してください。コード本体は変更しないでください。」

返答が理想形なら、日本語で処理の流れが説明され、その下に英語コメント案が出ます。
ここでAIの返答に英語の説明文が混じることがあります。
その場合は遠慮なく、次の一文を重ねると整いやすくなります。

「説明は日本語で、コメントは英語で統一してください。」

この再指示は実際に効きます。
モデルごとに説明の癖が違うので、最初からきれいに分かれないことはありますが、言語の役割を一段具体的に書くと揃ってきます。
「日本語で返して」だけだと、コメントまで日本語化されることがあるため、どこを日本語、どこを英語にするのかを分けて書くのが判断材料になります。

実例としては、次のような往復になります。

最初の依頼: 「この fetchUserProfile 関数の処理を日本語で4行以内に要約してください。
続けて、英語のコードコメントを2行だけ提案してください。
」

返答が英語混じりだったときの再依頼: 「説明は日本語で、コメントは英語で出してください。技術用語の関数名やAPI名は原文のままで構いません。」

この形にすると、日本語の説明が読みやすくなりつつ、fetch、response、cache のような技術語はそのまま残せます。
技術用語まで無理に日本語へ置き換えるより、説明の骨格だけ日本語、コードに近い語は英語のままのほうが、実際の編集画面では意味が崩れません。

初心者が最初に試す小さな変更例としても、この組み合わせは扱いやすいのが利点です。
日本語で「何の関数か」を掴み、その直後に英語コメントを1つ足すだけでも、AIを読む道具として使う感覚と、書く補助として使う感覚の両方が入ってきます。
日本語化の価値は、UIが読めることだけでなく、こうした理解と言語運用の切り替えを短い往復で回せることにあります。

料金・プラン補足と最新情報の見方

主要プランと利用枠の目安

Cursorの個人向け主要プランは、公式のCursor 料金プランで確認した時点で、Proが月額20ドル、Teamsが1ユーザーあたり月額40ドル、Ultraが月額200ドルという構成です。
個人でまず触るならPro、複数人でライセンス管理や共有運用まで見据えるならTeams、利用量を多めに取りたいならUltra、という切り分けで捉えると全体像がつかみやすくなります。
価格表だけだと差が見えにくいのですが、実務では「誰が使うか」より「どれくらいAI呼び出しを回すか」で体感差が出ます。

利用枠の読み方で押さえておきたいのは、2025年6月の公式説明で、Proには少なくとも20ドル分の利用枠が含まれると案内されている点です。
同じ説明では中央値ベースの利用例として、Sonnet 4なら約225回、Geminiなら約550回、GPT 4.1なら約650回相当という目安も示されていました。
ここで見るべきなのは、単純な回数そのものより、選ぶモデルで消費感が変わることです。
重めのモデルで長文のやり取りを続ける月と、軽めのモデルで要約や補助中心に回す月では、同じProでも余り方が変わります。

筆者は導入前にPricingとChangelogを一度並べて見て、月初に「今月は要約中心か、コード生成中心か」を先に決める運用にしていました。
たとえば最初の段階では、重い編集を毎回AIに任せるより、ファイル要約、日本語説明、Docstring案の作成を多めに回したほうが利用枠の感覚をつかみやすかったです。
料金表だけ見て判断するより、どのモデルをどの作業で使うかまで想定したほうが、月の途中で想定外に減ったと感じにくくなります。

チーム導入の目安としては、Enterpriseページにある社会的証拠も参考になります。
Cursorは50,000社以上に選ばれています。
もちろん、これはそのまま中小チームの導入効果を保証する数字ではありません。
ただ、個人向けツールの延長というより、組織利用まで含めて伸びている製品だと把握する材料にはなります。
特にTeamsやその先の運用を考えるときは、単なるエディタ課金ではなく、権限管理や標準化と一体で見るほうが実態に近いです。

Cursor · 料金プラン

自分に合ったプランを選ぶ

cursor.com

最新アップデートの確認先

機能面の変化を追うなら、いちばん見ておきたいのはCursor Changelogです。
料金表はプランの骨格を見る場所ですが、実際の使い勝手は更新履歴のほうに出ます。
会話の扱い方や操作感に関わる変化を追えます。
日本語化や返答言語の調整を終えたあとに効いてくるのは、こうした日々の操作部分です。

筆者も導入時は、まず料金を見て終わりにせず、更新履歴まで読んでから使い始めました。
その月に追加された機能が自分の作業に関係あるかを先に見ておくと、「このプランで足りるか」「今月は新UIに慣れる時間を取るか」といった見積もりが立てやすくなります。
特にCursorはAIモデルの選択肢だけでなく、チャット画面やエージェント周りの体験も変わるので、価格と更新履歴を別々に見るよりセットで見たほうが判断しやすくなります。

料金も仕様も固定ではなく、実際には説明ページと更新履歴の両方を読んだときに全体像が見えてきます。
月額だけを覚えておくと、利用枠の扱い方や新機能の前提を読み落としがちです。
Cursorを継続的に使う前提なら、Pricingで契約の枠組みを把握し、Changelogで今の挙動を追う、という見方のほうが実務に沿っています。

まとめと次のアクション

Cursorの日本語化は、表示まわりとAIの返答方針を分けて整えると、最初のつまずきが一気に減ります。
UIは日本語で読める状態にし、AIには日本語で説明させる一方で、コードコメントや技術語は英語を残す。
この役割分担を早めに決めておくと、後から設定が増えても軸がぶれません。
筆者は新しい環境を触るとき、最初の30分でこの記事の手順をそのままなぞり、表示言語、Rules、保存まわりだけ先に固めています。

今日やるチェックリスト

• Japanese Language Pack for Visual Studio Codeを入れ、表示言語を切り替えて再起動する
• AIの返答方針を決め、「説明は日本語・コメントは英語」をRulesかプロンプトに入れる
• Auto SaveFormat on Saveを有効にし、インデント設定を自分の案件に合わせて統一する

明日以降の設定メンテと学び先

次に触るなら、ショートカットと拡張機能を最小構成で見直す段階です。
最初から盛り込みすぎるより、毎日使う操作だけを残したほうが、どの設定が効いているか判断しやすくなります。
チームで導入するなら、個人設定を配る前に、コメントの言語規約と共通設定の合意を先に固めると、レビュー時のズレを抑えられます。
新機能の変化を追うときはCursor Changelogを起点に見ると、今の運用ルールをどこまで保つか判断しやすくなります。