Antigravity 2.x を日本語で使う — UI・AI応答・プロンプトを整える5つの層

Antigravity を日本語で使うための設定は、実は1箇所ではありません。「Settings で日本語を選んだのに AI の返事が英語のまま」という状態に、最初は戸惑う方が多いはずです。これは UI 言語と AI 応答言語が別々の設定になっているために起こります。

個人開発者として Dolice Labs の4つの技術サイトを日英2言語で書き分けているのですが、その日々の道具が Antigravity です。私自身、この「層の分かれ方」を理解してからは、設定の迷子がなくなりました。

日本語化は5つの層（UI・AI応答・プロンプト・IME・エンコーディング）に分けて考えると整理がつきます。それぞれの設定と注意点を、触る順番のとおりに見ていきます。

まず、自分がどのバージョンにいるかを確かめる

層の話に入る前に、確認しておきたいことが1つあります。日本語UIの設定の置き場所は、バージョンによって変わりました。 検索で見つかる手順が自分の画面と噛み合わない原因は、たいていここです。

やっかいなのは、新バージョンが段階的に配布されることです。公式のリリースノートに載っている機能が自分の環境にはまだ来ていない、ということが数日単位で起こります。「記事のとおりにやったのにその設定項目が無い」ときは、手順を疑う前にバージョンを疑ってください。

以降の層1〜層5の考え方自体は、どのバージョンでも共通です。変わるのは層1の入口だけなので、2.x を使っている方は層1だけ上の記事に読み替えて、層2から先はこのまま読み進めていただければ噛み合います。

層1: UI の日本語化 — まず Settings の Language から

インストール直後にやることは1つだけです。設定画面（Settings）の「Language」で「日本語」を選択し、再起動します。メニュー、ダイアログ、ボタンラベルが日本語に切り替わります。

この設定はプロジェクト単位ではなく Antigravity 全体に適用されるので、複数プロジェクトを行き来しても言語が混ざることはありません。

2.x 系では前述のとおり、ここが言語パック・コマンドパレット・AI 応答言語の3点に分かれています。UI だけを日本語にしてコマンドパレットは英語のまま残す、といった使い分けもできるようになりました。私はコマンドパレットを英語のまま残しています。コマンド名を英語で覚えてしまっているので、日本語に訳されるとかえって探せなくなるためです。

層2: AI 応答の日本語化 — 「UIは日本語なのに返事が英語」の正体

UI を日本語にしても、チャットエージェントの応答言語は別の設定です。応答が英語のままの場合は、設定で AI 応答言語（response language）を日本語に指定するか、プロジェクトのカスタム指示に「常に日本語で応答してください」と書きます。

私のおすすめはプロジェクト設定ファイルに書く方法です。マシンを乗り換えても、チームメンバーが clone しても同じ挙動になるからです。

// プロジェクトのカスタム指示（例）
常に日本語で応答してください。
コード以外の説明文・計画・コメントはすべて日本語で書いてください。
変数名・関数名・コミットメッセージは英語のままにしてください。

最後の1行が地味に重要です。応答言語を日本語に寄せると、AI がたまに変数名やコミットメッセージまで日本語にしようとします。「自然言語は日本語、コードの語彙は英語」と明示的に線を引いておくと安定します。

個々のプロジェクトではなく全体に効かせたいとき

サイトを横断して同じ挙動にしたい場合は、プロジェクトごとの指示を書くより、ユーザー全体に効くグローバルなルールに一度だけ書いておく方が楽です。Antigravity の設定で「常に日本語で応答」をグローバルルールに登録しておくと、新規に開いたプロジェクトでも初手から日本語で返ってきます。プロジェクト固有の指示は、その上書きが必要なときだけ書けば十分です。

私の運用では、グローバルに「説明は日本語・コード語彙は英語」を固定し、英語版の記事を書くプロジェクトだけ「このプロジェクトでは英語で応答」と上書きしています。この二段構えにしてから、日英を行き来しても応答言語のブレがなくなりました。

層2が通ったかを、その場で確かめる

v2.2.1 で、Antigravity 自身について尋ねると案内を返す Guide スキルが内蔵されました。これは応答言語の確認にちょうど使えます。「Antigravity のエージェントについて教えて」と日本語で尋ねてみて、日本語で返ってくれば層2は通っています。英語で返るなら、設定かカスタム指示のどちらかがまだ効いていません。

わざわざコードを書かせて確かめる必要はない、という程度の小さな話ですが、設定をいじった直後の確認手段があると切り分けが速くなります。

層3: 日本語プロンプトのコツ — 技術用語は英語のまま混ぜる

日本語プロンプトでも精度は十分出ますが、書き方で結果が変わります。私が効果を感じている順に挙げます。

まず、具体性です。「ボタンを作成して」よりも「クリック時に API を呼び出し、読み込み中はスピナーを表示するボタンを React で作成して」の方が、欲しいものが一発で出ます。これは英語プロンプトでも同じですが、日本語は主語や目的語を省略しがちなので、意識して補う価値があります。

次に、技術用語を無理に訳さないことです。「状態管理に Redux を使った React コンポーネント」のように、概念は英語・要件は日本語の混合が一番通じます。「冗長化された購読状態」のような訳語に置き換えると、かえって意図がぼやけます。

最後に、要件が3つを超えるなら箇条書きにすることです。改行された箇条書きは1項目ずつ認識されるので、長文で繋ぐより漏れが減ります。

層4: 日本語 IME まわりの注意点

Antigravity は Windows の IME、macOS の日本語入力、Linux の fcitx と組み合わせて使えます。ただし、変換中の文字列とエディタの補完がぶつかる場面はゼロではありません。変換確定前の文字がタブ補完に取られる・変換が乱れるといった症状が出た場合は、日本語 IME の変換が乱れる時の対処ガイドに OS 別の対処をまとめています。

日常的な予防策としては、長い日本語コメントを書くときに「メモアプリで書いて貼り付ける」のではなく、一文ずつ確定しながら書く方がトラブルに当たりにくい、というのが使い込んでの実感です。

層5: 文字化けと UTF-8 の統一

日本語の文字化けは、ほぼ全てファイルのエンコーディング不統一が原因です。プロジェクトルートに .editorconfig を置いて UTF-8 に固定しておくと、チームの誰が開いても同じ状態になります。

# .editorconfig
root = true

[*]
charset = utf-8

特に古い Windows 環境から持ってきた Shift_JIS のファイルが混ざっているプロジェクトでは、AI にファイルを読ませた時点で文脈が壊れるので、日本語化設定の前にまずエンコーディングを揃えることをお勧めします。

文字化けが一部のファイルだけで起きるときは、まずそのファイルが本当に UTF-8 かを疑ってください。macOS や Linux なら file コマンドで簡単に確認できます。

# エンコーディングを確認する（UTF-8 以外が混ざっていないか）
file -I src/*.ts
# → charset=utf-8 以外（shift_jis / iso-2022-jp 等）があれば変換対象

Shift_JIS のファイルが見つかったら、iconv でまとめて UTF-8 に変換しておくと、以降は AI も人も同じ文字で読めます。

iconv -f SHIFT_JIS -t UTF-8 legacy.ts -o legacy.utf8.ts

ターミナルと Git — 設定の外側で日本語が化ける2箇所

ここまでの5層を整えても、日本語が化ける場所がまだ2つ残ります。エディタの設定画面の外側にあるため、日本語化の手順からこぼれ落ちがちな箇所です。

そして、この2つはエージェントを使うときに効いてきます。エージェントはターミナルの出力を読んで次の判断をするので、git status の出力が化けていれば、化けたものを前提に考え始めます。人間なら「あ、文字化けだな」と読み飛ばすところを、エージェントは真に受けます。

Git が日本語ファイル名を数字の羅列で出す

git status で日本語のファイル名が "\346\227\245\346\234\254\350\252\236.md" のように出てくることがあります。これは Git が既定で非 ASCII をエスケープ表示するためです。設定1つで止まります。

# 日本語ファイル名をそのまま表示する
git config --global core.quotepath false

コミットメッセージとログの文字コードも UTF-8 に固定しておくと、環境をまたいでも読めます。

git config --global i18n.commitEncoding utf-8
git config --global i18n.logOutputEncoding utf-8

なお、日本語ファイル名は macOS と Linux でバイト列そのものが食い違う（濁点の扱いが違う）という、core.quotepath とは別の問題も抱えています。エージェントがファイルを開けない・差分が二重に出るといった症状に心当たりがあれば、日本語ファイル名が macOS と Linux で別物になるときにその話をまとめています。

Windows のターミナルが UTF-8 で喋っていない

Windows のコマンドプロンプトは既定のコードページが UTF-8 ではないため、日本語の出力が崩れます。統合ターミナルで一時的に切り替えるなら次の1行です。

chcp 65001

PowerShell を使っているなら、プロファイルに書いておくと毎回打たずに済みます。

# $PROFILE に追記
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8

macOS と Linux は既定で UTF-8 なので、この節は基本的に読み飛ばして構いません。ただし SSH で古いサーバーに入る場合は、そちらの LANG が C になっていると同じ症状が出ます。

設定が効いているかを確認する

層を設定したら、最後に効いているかを軽く確かめておくと安心です。私はいつも次の順で見ています。

第一に、UI のメニューが日本語になっているか。これは見ればすぐ分かります。第二に、エージェントに「いまの応答言語は何ですか」と一言聞いてみること。日本語で返ってくれば AI 応答層は通っています。第三に、日本語コメントを1行書いて保存し、再度開いて文字化けしないか。第四に、日本語のファイル名を1つ作って git status に通し、数字の羅列にならないか。ここまで揃えば、日本語環境としての土台は完成です。

応答だけ英語に戻ってしまうときは、層2のグローバル設定とプロジェクト指示のどちらかが上書きで打ち消し合っていることが多いです。プロジェクト側の指示を一時的に外して切り分けると、原因の層がすぐ特定できます。

症状別クイックリファレンス

迷ったときに最初に当てるための早見表です。

日本語コメントは AI への文脈供給にもなる

コード内の日本語コメントは Antigravity が正しく読み取ります。それだけでなく、AI への文脈供給としても機能します。

// ユーザーがページを訪問したときの初期化処理
const initializeApp = () => {
  // ローカルストレージからユーザー設定を読み込む
  const userSettings = localStorage.getItem('userSettings');
  // APIからユーザー情報を取得
  fetchUserData();
};

意図をコメントで書いておくと、続きの実装を依頼した時の提案が要件に寄ります。私のプロジェクトでは「なぜそうしているか」の理由コメントを日本語で残すようにしていて、数ヶ月後の自分と AI の両方がそれに助けられています。

設定としてやることは、UI 言語・AI 応答言語・エンコーディングの3点だけです。ターミナルと Git は、エージェントに仕事を任せ始めてから効いてくる部分なので、最初は後回しでも構いません。まず3点を固めてから、プロンプトの書き方を少しずつ自分の流儀に寄せていくのが、遠回りに見えて一番早い日本語化だと考えています。