Antigravity に日本語プロンプトを与えると応答品質が落ちる現実への対処 — 多言語運営者のハイブリッド戦略

実測: 同じタスクを日本語と英語で発行したときの差

私が個人開発しているアプリ群（壁紙系を含むいくつかの iOS/Android アプリ）の保守作業の中で、過去 2 週間に発生した類似タスク群を比較しました。条件を揃えるため、同じ機能のリファクタ依頼を、日本語のみのプロンプトと英語のみのプロンプトで同じ Antigravity プロジェクトに対して発行し、エージェントの初回提案がそのまま採用できたか、修正コメントを何回入れたか、最終的にテストが通るまでに何往復したかを記録しています。

サンプル数は対象タスク 24 件と少ないため、これは厳密な統計ではなく、あくまで現場感覚の数値として読んでください。

• 初回提案の採用率: 日本語 約 58% / 英語 約 81%
• ユーザー側の追加修正コメント数（採用に至るまで）: 日本語 平均 3.1 回 / 英語 平均 1.4 回
• 最終テストが通るまでのターン数: 日本語 平均 4.6 / 英語 平均 2.3
• 同一タスクの入力トークン量: 日本語のほうが英語より約 18% 多い（同等の説明を書くと日本語は文字数が伸びる）

特に効いてくるのは追加修正の回数です。日本語プロンプトの場合、最初の出力が「方向性は合っているが細部がずれている」という状態になりやすく、私の側で「ここはこう書き換えて、こちらは消して」という追指示を 2〜3 回挟む必要が出ます。英語プロンプトのほうは、最初の提案でそのまま採用できる確率が高く、結果として往復回数が半分以下になります。

数値は条件次第で変動しますが、ライブラリ固有の前提を踏まえる必要があるタスク（特定の RxJava 演算子の使い分け、CoreData のスレッドモデルを踏まえた書き換えなど）では、英語プロンプトの優位が露骨に出ます。逆に、UI 文言の表現提案や、仕様文書の要約、テストケースの命名候補など、自然言語側の作業では日本語プロンプトのほうが自然な出力になります。

ハイブリッド戦略 — どこを日本語のまま残し、どこを英語に寄せるか

「英語で書けば解決」という極端は、私個人としては推奨しません。理由は後述しますが、まず実用的なハイブリッド戦略を 3 階層に分けて提示します。

1. ユーザーへの会話・チャット応答: 日本語のまま。エージェントが私と話す部分は日本語で固定する
2. コード生成への指示部（システムプロンプト相当）: 英語で固定する
3. コードコメント・README・i18n 文言: コードコメントは英語、README とユーザー向け文言は日本語

これを Antigravity 側に伝えるための agents.md（または AGENTS.md、.cursorrules）は次のように書いています。

# Project Agent Rules
 
## Language Policy
 
- User-facing chat responses: Japanese (です/ます調)
- Internal planning, tool calls, and code-generation reasoning: English
- Code comments: English unless a Japanese comment already exists in the file
- README, CHANGELOG, and user docs: Japanese
- Commit messages: English imperative ("Add", "Fix", "Refactor")
- Variable names: English; do not romanize Japanese words
 
## When the user asks in Japanese:
1. Acknowledge briefly in Japanese
2. Switch to English internally for code planning
3. Present code with English comments
4. Summarize the result in Japanese at the end
 
## When generating diffs:
- Always show full file path and the reason for the change in Japanese
- Keep code changes minimal; explain in English why each change is necessary

この設定の狙いは、エージェントが内部でコードを組み立てる思考プロセスを英語側に寄せることです。私とのやり取りは日本語のままで、目に見える出力としての差はチャット部分にはほとんど出ません。ただし、生成されるコードや diff の質は、初手の段階から目に見えて安定します。

私の現場ではこの構成で、先ほどの 4.6 ターンが 2.7 ターン程度まで縮みました。完全英語プロンプトに匹敵はしませんが、会話の自然さを犠牲にせず、相当の品質改善が得られます。

翻訳レイヤーを噛ませる構成 — 軽量モデルで日→英→Antigravity→英→日

もう一歩踏み込んだ構成として、軽量モデルを翻訳レイヤーとして挟む方法があります。ローカルやサーバーサイドのスクリプト経由で Antigravity を叩いている場合に特に有効です。

# pseudo-flow: 日本語の意図を英語の精密な指示に変換してから Antigravity に渡す
from typing import Literal
 
def to_agent_prompt(user_intent_ja: str, mode: Literal["plan", "diff", "review"]) -> str:
    """日本語の意図を英語の構造化プロンプトに変換する。
    軽量モデル（Gemma 4 9B / Phi など）でも十分な品質が出る領域。
    """
    system = (
        "You are a translator that converts Japanese developer intent into "
        "precise English instructions for a coding agent. Preserve identifiers. "
        "Output only the English instruction, no preamble."
    )
    style_hint = {
        "plan": "Produce a numbered plan with file paths.",
        "diff": "Produce a unified diff with file paths. Minimal change.",
        "review": "Produce a checklist of risks and required tests.",
    }[mode]
    return f"{system}\n{style_hint}\nJP_INTENT: {user_intent_ja}"
 
# 呼び出し例
intent = "RxJavaのSingleをCoroutinesに置き換えて、エラーは上位で集約してほしい"
english_instruction = call_lightweight_model(to_agent_prompt(intent, "diff"))
# english_instruction を Antigravity のセッションに流す

この構成のメリットは 3 つあります。第一に、Antigravity への入力を英語で固定できるため、応答品質が安定します。第二に、変換ステップが「翻訳」というシンプルなタスクなので軽量モデルでも十分な品質が出て、コストもレイテンシも低く抑えられます。第三に、変換後の英語プロンプトを保存しておけば、後日同じタスクを別エージェントに流したいときに資産として再利用できます。

落とし穴は、変換ステップがブラックボックス化することです。私は最初の数日間、英語化された中間プロンプトを表示せずにフローを回していたのですが、軽量モデルが私の意図をわずかにずらして翻訳しており、応答全体がじわじわ的外れになっていました。今は変換後の英語プロンプトをログに残し、最終応答が芳しくないときは中間プロンプトを確認するようにしています。

Gemma 4 をローカルで動かしたときの日本語対応の現実

クラウド側の話に加えて、ローカル LLM の話も触れておきます。Antigravity は Gemma 4 をローカルモデルとして接続できる作りになっており、機微情報を含むコードを扱う場面では魅力的な選択肢です。ただし、日本語応答の品質という観点では、フロンティアモデルとの差は無視できません。

私が手元の Apple Silicon マシンで Gemma 4 を動かしたときの体感としては、英語プロンプトに対するコード生成は実用範囲、日本語プロンプトに対する応答は、フロンティアクラウドモデルに比べてもう一段品質が落ちるという印象です。これは前述の学習データ比率の問題が、モデルサイズが小さくなるほど顕在化するためだと考えています。

ローカル運用で日本語応答が必要な場合の私の運用は次の通りです。

• システムプロンプトは英語で書く（前述のハイブリッド戦略をそのまま流用）
• 出力の最終整形のみ、別途軽量モデルで日本語化する
• 機微情報を含むコードはローカル Gemma 4、それ以外はクラウド側の Antigravity と使い分ける

ローカル Gemma 4 の魅力は応答品質そのものより、外部にコードや会話を送らないという運用上の安心感にあります。私の場合、個人開発しているアプリ群のうち、決済処理や端末固有 ID を扱う部分はローカルモデル、汎用的なリファクタはクラウド側、と明示的に分けて運用しています。私はこの線引きを、応答品質ではなく扱うデータの機微さだけで判断するようにしています。

個人開発で実際にやっている使い分け — Lacrima/Mystery のようなブログ運営も含めて

私は Antigravity を、Lab 系の技術ブログだけでなく、別ジャンルの日本語ブログ（短編やノンフィクションを扱うサイト）の運用スクリプトの保守にも使っています。サイトごとに「どこを日本語のままにするか」のバランスが少しずつ違います。

技術ブログ側（この Antigravity Lab を含む）では、コード生成と diff の精度を最優先するため、エージェントへの指示は前述のハイブリッド構成で英語寄りに振っています。一方、別ジャンルの日本語ブログでは、本文の自然さが最優先のため、本文生成系のプロンプトは日本語で固定し、コード（自動投稿スクリプト等）の改修指示だけを英語寄りで切り出しています。

この使い分けは、agents.md をプロジェクトごとに置けるからこそ成立しています。グローバル設定で言語を固定してしまうと、「コードは英語、本文は日本語」のような細かな切り替えが面倒になり、結局どちらかに寄せてしまうことになります。agents.md をプロジェクトごとに用意するという小さな手間が、結果として全体の応答品質を底上げします。

「英語で書けばいい」が罠になる場面

最後に注意点として、英語プロンプトが裏目に出る場面も書いておきます。3 つあります。

ひとつは、ユーザーに見せる文言の生成です。エラーメッセージのユーザー向け文言、アプリストアのリリースノート、UI のラベル候補。これらを英語のシステムプロンプトで生成させると、日本語訳のニュアンスが平板になりがちです。日本語の語感は日本語で生成させ、英訳が必要なら別ステップで英語に変換するほうが、最終的な品質は高くなります。

もうひとつは、日本語固有の業務文脈です。月末締めの請求書フォーマット、和暦の取り扱い、敬語の使い分けに依存するメール定型文など。これらは英語プロンプトに変換すると意図の核が抜け落ちることがあります。

最後に、自分自身の理解の解像度を上げる対話です。英語で指示を書くと、書く側にも英語の精度が要求されます。私は最初の頃、英語でちゃんと書けていないせいで結局精度が落ちるという二重苦に陥りました。エージェントを使うことの本来の意義は、思考の負荷を下げて自分の意図を素早く具体化することなので、自分が窮屈になる言語を強いるのは本末転倒です。日本語で書いて変換レイヤーを挟むか、ハイブリッド戦略でチャット部分だけ日本語に残すか、自分の負荷を最も下げる構成を選ぶのが現実的だと考えています。

次に試すべき一手

ここまで読んでくださった方に、次の一手として勧めたいのは agents.md をプロジェクトルートに 1 ファイル置くことです。本記事で示したハイブリッド戦略のテンプレートをそのままコピーして配置し、半日だけ運用してみてください。コード生成の精度差を体感した上で、自分のプロジェクトに合わせて少しずつ調整していくのが、無理のない導入経路だと感じています。

最後までお付き合いいただき、ありがとうございました。みなさまのプロジェクトの応答品質が少しでも安定することを願っています。