海外向けに出しているアプリの説明文を、いざ言語を1つ増やそうとして手が止まったことがあります。日本語と英語まではなんとかなっても、そこにドイツ語やトルコ語が加わると、翻訳サービスとストア管理画面とテキストエディタを行き来するだけで午前中が溶けていきました。
2026年7月、Google スプレッドシートの Fill with Gemini が対応言語を28言語まで広げました。中国語・オランダ語・マレー語・ヘブライ語・ポーランド語・トルコ語などが加わり、自然文のプロンプトを1つ書くだけで、隣の列に各言語の訳を一気に埋められます。
私が惹かれたのは翻訳精度そのものよりも、「1枚のシートの中で作業が完結する」という一点でした。ストア説明文のように、行がタイトル・短い説明・詳細説明・リリースノートと分かれ、列が言語で並ぶデータは、まさに表計算と相性が良いのです。以下では、その1枚をどう組み、どこを人の目で止めるかを具体的にたどります。
なぜ翻訳ツールではなくシートで組むのか
多言語のストア説明文には、翻訳の正しさとは別の制約が絡みます。タイトルには文字数の上限があり、キーワード欄には検索されやすい語を入れたい。詳細説明では改行やリスト記号がそのまま表示される。こうした「翻訳の外側にある要件」を、翻訳ツールの1入力1出力の画面で管理するのは骨が折れます。
スプレッドシートなら、原文の列の隣に各言語の列を置き、さらにその隣に文字数を数える関数の列を添えられます。翻訳と、制約のチェックと、最終的な貼り付け元が、同じ1枚に並ぶわけです。Fill with Gemini はその「翻訳の列」を自然文で一気に埋める役割を担ってくれます。
1枚のシートの組み方
行に翻訳対象の項目、列に言語を並べる形が扱いやすいです。私は次のような構成にしています。
| 行（項目） | ja（原文） | en | de | tr | 上限の目安 |
|---|---|---|---|---|---|
| アプリ名 | 原文を入力 | Fill 対象 | Fill 対象 | Fill 対象 | 30文字前後 |
| 短い説明 | 原文を入力 | Fill 対象 | Fill 対象 | Fill 対象 | 80文字前後 |
| 詳細説明 | 原文を入力 | Fill 対象 | Fill 対象 | Fill 対象 | 4000文字前後 |
| リリースノート | 原文を入力 | Fill 対象 | Fill 対象 | Fill 対象 | 500文字前後 |
原文の列（ja）だけを先に埋め、翻訳したい範囲を選択してから Fill with Gemini を呼び出します。このとき、ただ「翻訳して」と頼むのではなく、制約を含めて指示するのがこつです。たとえば「左隣の日本語を各列の言語に翻訳。アプリ名は30文字以内、記号や絵文字は使わず、宣伝的な誇張は避けて事実ベースで」といった具合に、上限と文体の方針を1文に織り込みます。
文字数の確認は、翻訳の列の右に =LEN() を置いておくと一目で分かります。上限を超えた言語だけ赤くなるよう条件付き書式をかけておけば、Fill の直後に「どこを詰めればよいか」がすぐ見えます。
機械翻訳をそのまま出さないための検証
ここが最も大事なところです。Fill with Gemini の出力は下訳としては十分に使えますが、ストアにそのまま貼るには早い、というのが私の実感です。特に次の3点は、言語ごとに人の目で止めています。
第一に、固有名詞と機能名です。自分のアプリ名や、独自の機能名まで律儀に翻訳されてしまうことがあります。翻訳してほしくない語は、プロンプトで「次の語は原文のまま残す」と列挙しておくと崩れにくくなります。
第二に、文字数の実際の見え方です。=LEN() は文字数を数えますが、ドイツ語のように単語が長い言語では、同じ文字数でもストアの表示上は窮屈に見えることがあります。上限ぴったりを狙わず、少し余白を残す方が安全です。
第三に、キーワードの自然さです。日本語で検索されやすい語をそのまま訳しても、その言語の利用者が実際に打ち込む語とは限りません。ここは翻訳の正しさではなく現地の検索習慣の問題なので、主要な言語だけでも、現地で使われている類似アプリの表現を一度眺めてから最終稿にしています。
数式やデータの検証を習慣にする発想は、Gemini in Sheets の数式エラー1クリック修正を、信用しすぎずに使う で書いた「AIの出力は下書きとして受け取り、最後は自分で確かめる」姿勢と同じです。翻訳でも、この一歩を省かないことが結局は早道になります。
リリースのたびに使い回す
一度この1枚を組んでおくと、更新のたびに原文の列だけ書き換えて Fill を呼び直せば、全言語の下訳が揃います。私自身、個人開発でアプリを回している都合上、リリースノートは毎回の更新点だけ差し替えるので、原文を直して Fill、文字数の赤を潰して、各言語の固有名詞を確認する、という流れが15分ほどで回るようになりました。以前の「午前中が溶ける」感覚と比べると、摩擦がずいぶん減った実感があります。
同じ考え方は、公開後のユーザー対応にも延長できます。多言語のレビュー返信をシートで管理する方法は、Google Play 多言語レビュー返信を Gemini と作る — 11 言語の温度感を維持する運用設計 にまとめています。説明文とレビュー返信で同じ言語列の構成を使えば、頭の切り替えも少なくて済みます。
使いどころと、任せない部分の線引き
Fill with Gemini の28言語対応は、個人でアプリを海外に出す立場にとって、確かに作業の入口を軽くしてくれます。ただ、便利になったのは「下訳を並べる」ところまでで、公開する言葉を決める最後の判断は、これまで通り自分の手元に残ります。
私は、対応言語を増やす一歩をためらう理由が「面倒くささ」だったなら、この機能はその理由を1つ消してくれると思っています。一方で、その言語の利用者にどう届くかを確かめる責任までは肩代わりしてくれません。任せる部分と、自分で止める部分。この線を最初に決めておくと、多言語化はずっと落ち着いて進められます。
まだ私も試しながらの段階ですが、実際にシートを1枚組んでみると、思っていたより気軽に言語を増やせます。この記事が、最初の1枚を作るきっかけになれば幸いです。お読みいただきありがとうございました。