---
title: プレースホルダーと翻訳におけるその扱い方
description: 翻訳におけるプレースホルダーは様々な問題を引き起こす可能性があります。翻訳やローカライゼーションプロジェクトでそれらに対処する方法をご説明します。
canonical: https://ja.smartcat.com/blog/place-holders-save-the-day/
language: ja
updated: 2026-01-29
---

# プレースホルダーと翻訳におけるその扱い方

初めて[ソフトウェアローカライゼーション](https://ja.smartcat.com/software-localization/)プロジェクトに携わった時のことを覚えています。 複雑なソフトウェアローカライゼーションツールを使って、ある産業用コンピュータシステムのユーザーインターフェースを翻訳する任務を任された。技術的な内容自体は問題なかったが、UIの翻訳は初めてで、この作業は本当に大変な挑戦となった。

実際、そのテキストのスタイルは私にとってそれほど奇妙ではなかった。ITに多少詳しい身として、ソフトウェアで典型的に使われる「コンピューター」言語をよく知っていたからだ（ただし、チャットボットや音声インターフェースの影響で、私の見方はその後劇的に変わった）。 本当に困惑したのは、*{0}*、*%d*、*%setup%*、*$stop$*といった奇妙な記号群だった。これらが何を意味するのか、記号に挟まれた単語を翻訳すべきか全く分からず、あっという間に数多くの誤訳を生み出した。 改行文字*\n*は、私の自信を完全に打ち砕く最後のとどめとなった。これまで見たこともない記号で、最悪なのは他の単語と結合されることが頻繁にあったことだ。 この状況が滑稽でなかったかのように、テキストはドイツ語だったため、*\nein*が「nein」なのか「\n」＋「ein」なのか見分けるのが非常に困難だった。プロジェクトマネージャーは、質問攻めに遭った後、私のような素人（ダミー）にこのタスクを割り振ったことを後悔したに違いない。Twitterで愚痴をこぼしたかもしれない。

緊急プロジェクトの翻訳ファイルから、プレースホルダーが魔法のように消えてしまった。#PM問題 #パニック開始

— Lau Velázquez (@geekylau) 2013年10月9日

プレースホルダー $DepartureTime$ を $HeureDépart$ と翻訳する翻訳者は、単に一貫しているだけなのです。

— Olivier Oswald (@ooswald) 2011年7月27日

*プレースホルダー「$Departure Time$」を「$HeureDépart$」と翻訳する翻訳者たちは、一貫しているだけです。*

翻訳者が引用符の形式を変更すると決めた瞬間、ゲーム内の変数の半分が消えてしまう。

— Vojtěch Schubert (@falagor)[2016年1月12日](https://twitter.com/falagor/status/686925355991588864)

何年も経った今でも、初めての経験を思い出すと笑みがこぼれます。言うまでもなく、私は常に翻訳者と時間を取って変数の仕組みを説明します。そして、間違いを防ぎ、自分とチームの時間を節約する究極の方法は正規表現を使うことです。正規表現を使えば、変数を編集不可で追跡しやすいオブジェクトに変換できます。ソフトウェアによって、これらのオブジェクトは異なる名称で呼ばれます。 Smartcatではこれらを「プレースホルダー」と呼んでいます。正規表現とは何か気になる方もいるでしょうが、世間話とは全く関係ありません。文字列の組み合わせを照合・操作するためのパターンです。正規表現を学ぶのにプログラミングスキルは不要です。Yamagata Europeのローカライゼーション専門家Thomas Vackierが作成したこの超簡単なプレゼンテーションをクリックして、正規表現（regex）の基本を掴んでください。

**神秘的な記号たち**

簡単な例として、ザ・プロクレイマーズの曲『アイム・ゴナ・ビー（500マイル）』の歌詞を数行引用しましょう：

*だが俺は500マイルも歩こうさらに500マイルも歩こうただ千マイルも歩いた男になるために君の戸口で倒れ込むために*

さて、リスナーが別の場所へ移動するたびにこの歌詞を変えたいとします。そのためには変数が必要です：

*でも君のもとへたどり着くために%$1マイルも歩こうさらに%$2マイルも歩こう千マイル歩いた男になるために君の{location}でひれ伏すために*

ここに潜む危険は？ 重要な文字が削除されたり誤用されたりする恐れがあります。%$1s内の数字は連続したパターンに従う必要があり、「spelled-number」と「location」は翻訳対象外です。残念ながら、誰もがこのことを知っているわけではありません。

「初心者の混乱に対処するより、専門の翻訳者を雇えばいいのでは？」と疑問に思う人もいるだろう。実際の理由はともかく、覚えておく価値があるのは：生まれながらのローカライゼーションのプロはいないが、最初のステップを苦労して踏み出し、その過程で貴重な経験を積んだ者なら誰でも、プロになれるということだ。

**初心者対策、あるいは世界を救う方法**

では、こうした災難を防ぎ編集時間を節約するにはどうすればよいか？変数を正規表現で記述してみましょう：

- 連続した数字の変数の場合： *%\$\ds*

- 中括弧で囲まれた変数：*\{.+?\}*

正規表現の作成にはこのチートシートが非常に役立ちます。テストにはregex101.comという優れたオンラインツールをお勧めします。 それでは変数を含むファイルをSmartcatにアップロードしてみましょう。以下のような画面が表示されます：

変数は紫色の単位として表示され、明らかに翻訳不可能であり、キーボードショートカットでソーステキストからターゲット言語へ安全に転送できます。これらの要素はダウンロード後も翻訳文書内でそのまま残ります。プレースホルダーの使用はローカライゼーションプロジェクトに限定されません。 例えば、数千の項目が記載された大型空気ポンプの仕様書があるとします。各項目には注文コードが割り当てられていますが、それらはすべて非常に似通っているため、誤って入力してしまう可能性が高いのです。

ここで一つでもミスをすれば、結果は非常に不幸なものになる可能性があります。倉庫からの出荷時にエラーが発生する可能性があり、適切な設置も問題になる場合があります。顧客は損失を被るか、さらに悪いことに：誤ったデータは技術的問題を引き起こし、それが環境災害につながる可能性があります。プレースホルダーは翻訳せず、安全に対象言語に移行するだけでよいのです。では、なぜそれらに時間を浪費するのでしょうか？ この洗練された正規表現 *[A-Z]{2}\d{4}\-\d{4}* で全注文コードを抽出し、魔法のように編集不可要素へ変換しましょう：

翻訳プロセス（編集作業も含め）をより簡単かつ迅速にする素晴らしい方法ですね！

現時点では、プレースホルダーは一般的なローカライゼーションファイル形式でのみデフォルトでサポートされています。他のドキュメントタイプで使用したい場合はお知らせください。

同僚たちにプレースホルダーの使用経験について尋ねてみました。

**フィョードル・ベズルコフ**、Logrus IT（キエフ事務所）エグゼクティブディレクター

*「ドキュメント形式でのプレースホルダーとタグの使用は、私たちの日常業務において一般的な作業シナリオです。クライアントからHTMLやXMLマークアップを含むExcelファイルが送られてきた際には、これらが命の恩人となります。Smartcatがプレースホルダーと正規表現をサポートしているおかげで、こうしたリソースの取り扱いが格段に容易かつ便利になりました。」*

**マリーナ・イリニフ**、Bookmate ローカライゼーションマネージャー

*「当社のアプリUIでは変数と書式設定を多用しています。タグや変数をプレースホルダーで置き換えることで、自動的な整合性チェックを実行し、価格、購読日、リンクなどの重要なデータを保護できます。」*

lexiQAのCEO、ヤニス・エヴァンゲロウは複雑な心境を語った：

**ヤニス・エヴァンゲロウ**, lexiQA CEO

*「翻訳者がプレースホルダー、トークン、タグ内のテキストを翻訳する際によくある問題があります。エスケープ文字も頻繁に無視されます。 彼らの大半は、これらが翻訳対象の語彙単位ではないことに気づいていません。プロジェクトマネージャーも同様です。しかし、この種の不注意は重大なエラーを引き起こす可能性があります。ある翻訳者は、HTMLフォーマットを含むテキストを扱わなければならず、実際に という行を を と翻訳したことがある。彼は「これを使う開発者は英語を話さないかもしれない」と主張した。PMは翻訳者の理屈が…妥当だと思ったため修正しなかった！」*

すると、ゲームローカライゼーションの専門家であるロルフ・クリシェフスキーが口を挟んだ：

「ゲーム翻訳者はよくこんな問題に直面します：」

そして、もちろん、それに伴う様々な問題も存在します。

ここで問題となるのは、一部の目的地には冠詞が必要だということです。つまり「the Bahamas」ですが「Barbados」です。ドイツ語では「Switzerland」が「die Schweiz」となります。こうしたケースでは、プロジェクトを断ることがよくあります。通常、クライアントにはテキストエンジンを変更するよう勧めます。粗悪なものを納品したくないからです。 開発者は大抵こう聞きます：「そんなに大きな問題なの？」確かに、ゲーム自体は遊べるので、そうとも言えます。では、こうした問題をどう扱うか？クライアントに説明し、問題を伝えることです。もし彼らがエンジンを修正できない、あるいは修正しない場合で、あなたにお金が必要な時は、仕事を引き受けますが、クレジットに名前が載らないようにしてください。」