言語に欠けていたオペレーティングシステム

チームが一貫して働くための共通ツールを提供するという点で、ソフトウェアがどれほど進歩してきたかを考えてみてください。フレームワークによって、開発者は予測可能なパターンでロジックを表現できます。デザインシステムによって、デザイナーとエンジニアは、あらゆる画面や接点で共通のビジュアル言語を使用できます。Gitは、共同作業、バージョン管理、レビューの基盤を提供し、GitHubとGitLabは、それを何百万人もの人々が毎日利用する仕組みへと発展させました。

次に、言語について考えてみてください。プロダクトが人々に実際に伝える言葉。エラーメッセージのトーン。マーケティング文が日本語で与える印象と、ドイツ語で与える印象の違い。サポートチームが使用する用語と、プロダクトのユーザーインターフェースに表示される用語の違い。

これらを扱う共通の仕組みは存在しません。フレームワークも、デザインシステムも、Gitもありません。何もないのです。

私たちはインフラストラクチャを構築してこなかった

理論が存在しないわけではありません。言語学には豊かな蓄積があります。ユージン・ナイダの動的等価という概念は、優れた翻訳とは単に単語を置き換えることではなく、読者とメッセージの間にある同じ感覚的な関係を再現することだと教えてくれました。談話分析、語用論、社会言語学など、これらの分野はすべて、文脈の中で言語がどのように機能するかを何十年にもわたって研究してきました。知的基盤はすでに存在しています。

しかし、その基盤を中心とした仕組みを構築した人はいませんでした。

インターネットが登場すると、ローカリゼーション企業は独自のデスクトップアプリケーションをブラウザへ移行しました。基礎となるモデルは変わりませんでした。翻訳メモリ、あいまい一致、単語単位の料金体系です。企業は同じ基盤の上に構築を続け、機械翻訳が進歩すると、それを上乗せしました。再考も、再構想もありません。基盤となるエンジンが高速化されただけで、ワークフローは同じままでした。

そして、仲介業者が登場しました。

コンテンツを持つ個人または企業であるあなたと、言語を実際に理解する言語専門家との間に、仲介業者による一大産業が生まれました。連携プラットフォーム。翻訳管理システム。翻訳会社。品質保証レイヤー。プロジェクト管理ダッシュボード。それぞれが複雑さを増し、それぞれが利益の一部を得ます。最も大きな価値を生み出す人、つまり文化への理解、用語の正確性、創造的な判断力をもたらす言語専門家は、最終的に連鎖の末端へ追いやられ、最も少ない報酬しか得られません。

業界の報告書によると、人工知能による翻訳のポストエディット単価は、もともと低い単語単価の50〜70%まで下がる場合があり、さらに翻訳会社はそこから30〜40%の値引きを求めます。このサプライチェーンは、最も依存している人々を圧迫しています。

何かが欠けている兆候

現在のツールでは不十分であることを示す事実があります。企業が「言語マネージャー」という役割を設けていることです。この役割を担う人々は、用語の管理、翻訳ワークフローの監督、用語の一貫性の確保、言語専門家、プロダクトチーム、マーケティング部門間の調整を専任で行います。

この役割の存在自体が一つの兆候です。組織はあらゆる接点で言語的一貫性を必要としていますが、既存のツールではそれを実現できていません。そのため、人を雇って全体をつなぐ役割を担わせています。

そして、その人々は難しい二者択一に直面します。一方では、社内システムを構築するためにエンジニアリングリソースを求めることができます。しかし、それには雇用主の中核事業ではないものへ莫大な投資が必要です。もう一方では、外部ツールを探すこともできます。しかし、この課題に対する包括的なソリューションは、まだほとんど構築されていません。存在するのは、小規模で相互に接続されていないツール群であり、自ら連携させ、つなぎ合わせる必要があります。どちらの選択肢も満足できるものではありません。

まさにこの空白をシステムが埋めるべきです。言語マネージャーを置き換えるのではなく、言語マネージャーと、その協働相手であるすべての言語専門家が業務を遂行するための適切なオペレーティングシステムを提供するのです。

Glossiaで構築しているもの

私たちが考える答えは、翻訳ツールというより、GitHubがコードにもたらしたものに近いものです。

GitHubは、ファイルの変更を追跡するシステムであるGitを、開発者が互いの作業をレビューし、変更について議論し、共同で反復改善できるプラットフォームへと発展させました。GitHub以前は、ソフトウェアプロジェクトに貢献するには、ファイルをメールで何度も送り合う必要がありました。GitHub以後は、アカウントを持つ誰もが参加できるようになりました。

私たちは、言語でも同じことを実現したいと考えています。

Glossiaは、組織が言語上の選好、ボイス、用語、トーン、対象読者への期待を記録し、言語専門家がそれらの選好を反復改善する中心となるオペレーティングシステムです。工程の末端ではありません。三層もの仲介者の背後でもありません。中心です。

これについては、コンテキストグラフに関する記事でも説明しました。私たちは、組織が長期にわたって蓄積する言語に関するあらゆる知識を記録する、相互につながった構造化マップを構築しています。ボイスの定義、用語エントリ、対象読者のプロファイル、敬体や常体などの文体規則です。それぞれがバージョン管理されているため、いつ何が変更されたかを確認でき、関連するあらゆる情報と接続されています。何かが変更されると、影響を受けるコンテンツと、再確認が必要な箇所をシステムが正確に把握します。

これはGlossia上のあなたのアカウントと、あなたが貢献できる数多くのプロジェクトです。言語専門家は複数の組織にまたがって活動し、それぞれ異なるコンテキストに専門知識を提供し、自らの判断がシステム全体へ波及する影響を確認できます。GitHubで複数のプロジェクトに貢献する開発者と同じように、Glossiaの言語専門家は、数十ものプロダクトの言葉遣いを形づくることができます。

AIは代替ではなく増幅の手段

AIと言語をめぐる主流の論調は、人間の代替に焦点を当てています。より速く、より安く、より少ない人数で実現するというものです。私たちは、その考え方は根本的に誤っており、率直に言えば、言語専門家がもたらす高度な専門性への敬意を欠いていると考えています。

私たちの見方は異なります。AIは、言語の専門知識によって形づくられたシステム上で動作するツールです。言語専門家を置き換えるものではありません。言語専門家が可能にすることを増幅します。

言語専門家がGlossiaでボイスの定義を改善すると、その改善はシステムが扱うすべてのコンテンツへ反映されます。用語専門家が用語エントリを更新すると、その組織向けにエージェントが次にコンテンツを生成または変換する際、その更新が反映されます。人間の判断が、数百件、数千件の出力へ展開されるのです。これは、これまで実現できなかった規模の効果です。

翻訳は最も分かりやすいユースケースであり、私たちが最初に取り組んだ領域です。しかし、それだけではありません。組織が、言語専門家のチームによって数か月、数年かけて蓄積された言語的な記憶を含む豊かなコンテキストグラフを構築すると、可能性はさらに広がります。

• マーケティングチームは、MCP（Model Context Protocol。AIツールが外部システムと通信するための標準規格）を通じて執筆ツールをこのOSに接続し、すべてのキャンペーンが会社の用語とボイスに準拠するようにできます。
• プロダクトチームは、UIの文言が対象読者向けに定義されたトーンと一致しているかを検証できます。
• サポートチームは、汎用的なチャットボットではなく、ブランドらしい応答を生成できます。

言語に関する知識は、デザインシステムの言語版のような共有リソースになります。

言語専門家には、より優れたツールが必要です

これを読んでいる言語専門家や翻訳者の方に知っていただきたいことがあります。このプロジェクトは、皆さまの存在があってこそ生まれたものであり、皆さまを差し置いて進めるものではありません。

ローカライゼーション業界は長年にわたり、皆さまを、その専門知識を必要とする人々や組織から遠ざけてきました。皆さまの仕事をコモディティ化し、報酬を引き下げ、処理量を最優先する工程の中で、その専門性を後回しにしてきました。

私たちは、組織のコミュニケーションにおいて、言語専門家が第一級の参加者であるべきだと考えています。皆さまは、言語使用域、語用論、文化的背景、そして文章が表す内容と実際に意味する内容との微妙な違いを理解しています。それを置き換えられるモデルはありません。一方で、システムによって皆さまの知見をより広く届け、より長く残し、個々の翻訳を超えて大きな影響を与えられるようにすることは可能です。

私たちは、皆さまの専門知識が、ほかのすべてを支える基盤となるようGlossiaを構築しています。一連の工程の最後に置かれる一工程ではありません。基盤そのものです。

今後の展開

私たちはまだ初期段階にいます。CLIエージェント（コマンドラインツール。視覚的なインターフェースでボタンをクリックするのではなく、ターミナルにコマンドを入力して操作します）から始めたのは、ソースファイルの読み込み、出力の生成、独自ツールによる検証、フィードバックループの完結といった、最も難しいインフラストラクチャ上の課題がそこにあるためです。しかし、最初の記事で説明したとおり、ターミナルは最初のインターフェースであって、唯一のインターフェースではありません。

私たちは、言語専門家がコンテンツとコンテキストを並べて確認し、共同セッションを通じてボイスの定義を洗練し、自らの判断がリアルタイムでシステム全体に反映される様子を確認できる体験を設計しています。言語の専門知識を提供する体験を、GitHubでコードに貢献するのと同じくらい自然で有意義なものにしたいと考えています。

使用を求められるツールによって蚊帳の外に置かれていると感じてきた言語専門家、あればよいと願っていたシステムを探しているランゲージマネージャー、あるいは、何を構築するかと同じくらい、どのように伝えるかも重要だと考える方など、ここまでの内容に共感いただけるなら、ぜひお話をお聞かせください。Discordに参加するか、ブログをご覧ください。対話は、まだ始まったばかりです。