ChatGPTが用語集を忘れてしまう理由
すべてのセッションは用語ベースがない状態で始まる
用語管理システムとチャットウィンドウの間には、何のチャネルも存在しません。それぞれの会話は、一般的な言語しか知らず、承認された用語については何も知らないモデルから始まります。そのため、用語集は手動で持ち込むしかありません。これを4つの言語で作業する6人のローカライズチームで行うと、同じリストが週に何度も、それぞれ微妙に異なる更新状態のまま貼り付けられることになります。
用語集（Glossary）は用語ベース（Termbase）ではない。その違いがすべて
用語集（グロッサリー）は、承認された原文の用語とそれに対応する訳語をペアにしたフラットなリストです。一方、用語ベース（タームベース）は、品詞、文法上の性、使用コンテキスト、規制ステータス、承認日などのメタデータを各エントリーに追加した構造化データベースです。このメタデータこそが用語を使用可能にするものであり、翻訳者が Arbeitsbereich が男性名詞であること、この用語が単なる好みではなく規制上の表現であること、そしてそのエントリーが前回の法務レビューの後に承認されたものであることを知る手がかりになります。
チャットに用語集を貼り付けるとき、送信できているのはせいぜいそのフラットなレイヤーだけです。モデルは2つの列を受け取り、残りを推測します。これこそがエラーの発生源です。
文脈に合っているか確認せずに用語が適用される
これは実務担当者が最も頻繁に報告する失敗であり、直感に反するものです。モデルに用語集を与えることで、かえって出力が悪化することがあります。特に用語集にかなり一般的な単語が含まれている場合、用語が文脈において常に正しいとは限りません。モデルは用語集で単語を目にすると、その意味が一致しているかどうかにかかわらず、その単語が現れるすべての場所でそのエントリーの訳語を使用する傾向があります。UIラベル用に承認された用語が、別の意味を持つ法的な段落の中で使用されてしまうといったことが起こります。
用語ベースの「使用コンテキスト」フィールドは、まさにこれを防ぐために存在します。貼り付けられた2列のリストでは、これを防ぐことはできません。
レビュアーによる修正が蓄積されない
言語レビュアーは毎週同じ3つの箇所を修正しています。チャットのワークフローでは、それらの修正はドキュメントに反映されてそこで終わってしまいます。エラーを出したモデルには修正された記憶がないため、次のファイルでも同じエラーを繰り返します。その一方で、用語集の品質も別の方向で低下していきます。誰も積極的にレビューやメンテナンスを行わない用語ベースは、AIの関与の有無にかかわらず劣化していくものです。
ローカライズチームが試みること
すべてのプロンプトに用語集を貼り付ける。 汎用的であり、セッション内では機能します。しかし、リクエストごとに対価となるトークンを消費し、用語ベースが数千エントリーに達すると限界を迎えます。また、誰かがチャットスレッドで共有した古いコピーを使い続けることで、いつの間にか内容が古くなってしまいます。
用語集をナレッジファイルとして持つカスタムGPT。 これは確実な改善です。再貼り付けすることなく用語が存在します。ただし、これは静的なスナップショットであるため、用語が変更されるたびに誰かが再アップロードする必要があり、依然としてメタデータではなくフラットなリストしか送信されません。
カスタム指示（Custom instructions）。 少数の重要な用語やトーンのルールには適しています。しかし、用語ベースを置く場所としては不適切です。
用語ベースの強制機能を備えたCATツールまたはTMS。 これがプロフェッショナルな解決策であり、はっきりと述べるべきです。翻訳支援（CAT）ツールは承認された用語ベースを保存してそれを強制し、逸脱をフラグ立てするQAチェックを備えています。これは、プロンプトが提供する保証とは次元が異なります。現在、プラットフォームは、モデルに「お願い」するのではなく、LLMの出力に対して決定論的な用語制約を適用するために特別に設計された用語集サポートを提供しています。翻訳ボリュームがそれに見合うのであれば、これを使用すべきです。
用語データベースに対するリトリーバル（検索）。 貼り付けよりもカバー範囲が広く、スケールします。しかし、リトリーバルはクエリに類似したエントリーを返すだけであり、どのエントリーが現在承認されているか、あるいはなぜ前回のエントリーが却下されたのかを認識していません。これが、リトリーバル単体ではメモリとは言えない理由です。
解決策：ChatGPTに永続的な用語メモリを提供する
TMSの外で発生する作業（原文のドラフト作成、マーケティングテキストの翻案、「これはどう表現すべきか」への回答、フリーランサーへの指示、翻訳パイプラインに到達する前のUI文字列の作成など）において、実用的な解決策は、用語を手動で持ち込むのをやめ、モデルが読み取れるレイヤーに配置することです。
MemoryLake は、まさにそのような形状のメモリレイヤーです。単一のAIツールの外部に存在し、MCPまたはAPIを介してアクセスできるため、チームがどのアシスタントを使用していても、同じ用語メモリを利用できます。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを実行できます。
ステップ 2: 最初のメモリをアップロードする
言語を実際に管理している用語アセットをロードします。メタデータがそのまま残っている用語ベースのエクスポート、スタイルガイド、翻訳除外（DNT）リスト、ブランドおよび製品の命名規則、ロケール固有の慣習、そして候補用語が却下された理由を記録したレビュアーの決定ログなどです。ドキュメント、画像、その他のファイルはすべて同じ場所に保存されるため、PDFのスタイルガイドや承認されたUI文字列のスクリーンショットも、スプレッドシートと同じように活用できます。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、その他のエージェントにMCP経由でアクセスを許可します。ネイティブのMCPクライアントを持たないコンシューマー向けのChatGPTについては、APIを介して関連する用語を取得し、ドラフト作成プロンプトに注入します。あるいは、コンテンツチームがすでに使用している社内ツールにその取得を自動的に行わせることで、ライターが意識することなく利用できるようにします。
維持すべき2つの境界線。 第一に、メモリレイヤーは用語を利用可能かつ一貫したものにしますが、それを強制するものではありません。逸脱のチェック、言語レビュー、および最終承認は、依然としてQAプロセスやTMSの役割であり、規制対象のコンテンツ（医療、法務、財務、安全など）については、モデルではなく承認ワークフローが支配します。第二に、メタデータを用語と一緒に保持することです。フラットな2列のリストをメモリに送るだけでは、解決しようとしている文脈の問題が再発してしまいます。使用コンテキストやステータスのフィールドこそが、不適切な場所での用語の使用を防ぐ役割を果たします。
実務における変化
目に見える節約は、貼り付け作業の削減です。4つのロケールでコンテンツのドラフト作成や翻案を行う6人のチームは、現在、1日に何度も、セッションごと数分を費やして用語を再設定し、手元にある適当な用語集のコピーを使用しています。これを排除することで、時間とバージョンの不一致（ドリフト）の両方を解消できます。
より大きな効果は、レビューのループに現れます。レビュアーの決定が、ドラフト作成ツールが読み取るのと同じメモリに保存されていれば、一度行われた修正がその後の出力に反映されるようになり、何度も同じ議論を繰り返す必要がなくなります。これが、劣化していく用語集と、蓄積されていく用語集の違いであり、AI支援型ローカライズにおける品質への不満の大部分を占めるメカニズムです。
また、最新性の観点もあります。最も深刻な用語エラーは、一貫性のない同義語の使用ではありません。前四半期には正しかったものの、その後規制上の理由で変更された用語を使用することです。一箇所で更新される単一の用語メモリソースこそが、誰かが気づく前に4つの言語に誤った用語が拡散するのを防ぐ手段となります。
AI支援型用語管理のベストプラクティス
すべての用語に使用コンテキストを紐付ける
エントリーが 原文 → 訳語 としてしか伝達されない場合、誤って適用されることを覚悟しなければなりません。品詞、使用コンテキスト、ステータス、承認日を一緒に保持してください。メタデータは官僚的な手続きではなく、モデルに対してその用語をいつ使用すべきでないかを伝える指示なのです。
承認だけでなく、却下された内容も記録する
「この画面に対して『dashboard』は使用しない。読み取り専用のレポートを連想させるため」といった記録は、不毛な議論や不適切な翻訳を防ぎます。承認された用語はモデルに何を言うべきかを教え、理由付きで却下された候補は避けるべきものを教えます。後者は、ほとんど誰も保存していない重要な半分です。
モデルにドラフトを作成させ、パイプラインに強制させる
最も強力な役割分担は、ドラフト作成、翻案、用語の質問には一般的なアシスタントを使用し、決定論的な強制やQAは本来あるべき場所（CATツール、TMS、レビュアーの手元）に任せることです。永続メモリはドラフトを改善しますが、チェックの代わりにはなりません。同じ分担は、流暢さよりも一貫性が重要となるブランドガイドラインやライティングスタイルにも有効です。
結論
ChatGPTが用語集を忘れてしまうのは、そもそもそれらを持っていなかったからです。どのセッションも用語ベースを引き継ぐことはなく、貼り付けられたリストは実際の用語情報のフラットなレイヤーしか伝えず、用語は意味が一致する場所ではなく、その単語が現れるすべての場所に適用されてしまいます。レビュアーによる修正はドキュメントの中に消え去り、用語集は双方向で静かに劣化していきます。
カスタムGPTや貼り付けられたリストは、キュレーションの手間を犠牲にして対症療法を行っているにすぎません。プロフェッショナルな強制力はCATツールやTMSに属するものであり、翻訳ボリュームがそれに見合うのであれば、それが正しい投資です。パイプラインの前やその周辺で発生するすべての作業において、永続的な解決策は、チャットの外部に用語の「家」を提供することです。メタデータ、却下履歴、レビュー履歴をそのまま保持することで、今月11回目のドラフト作成であっても、汎用的な言語からではなく、承認された表現から開始できるようになります。もしあなたのチームが毎日同じ参照ファイルを再アップロードしているなら、その習慣にも解決策があります。