ローカリゼーションは過去に取り残されていました。私たちはそれを前進させるためにGlossiaを開発しました。

複数の言語でソフトウェアをリリースしたことがあれば、いつもの流れをご存じでしょう。ローカライゼーションプラットフォームを選び、リポジトリに接続した後は、同期の管理に時間を費やし続けます。コンテンツを送り出し、翻訳が戻ってくるまでのどこかで問題が発生します。

コンテンツをリポジトリから送り出し、再び戻すという絶え間ない往復作業。このオーバーヘッドは、現在のローカライゼーションツールを利用するすべてのチームが負担するコストです。些細なことに思えるかもしれません。しかし、金曜日の午後6時に翻訳のプルリクエストがサイトのビルドを壊した原因を調査する立場になれば、そうではないと分かります。

インターネット以前から受け継がれた設計

ほとんどのローカライゼーションプラットフォームは、現代の開発ワークフローよりも前に生まれた概念を基盤として設計されています。翻訳メモリ、あいまい一致、データベースから類似する文字列を提案するツールを使いながら、独自のエディター内で作業する人間の翻訳者です。

翻訳が手作業によるオフラインのプロセスだった時代には、これらの考え方は合理的でした。しかし、企業は翻訳メモリをベンダーロックインの仕組みに変えました。対価を支払って蓄積した過去の翻訳や組織の知識は、その企業のプラットフォーム内にあります。別のプロバイダーへ移行するには、最初からやり直すか、完全には機能しないエクスポートに費用を支払う必要があります。

その結果、業界全体が人為的な摩擦の上に成り立っています。コンテンツはリポジトリを離れてブラックボックスに入り、他者が決めたスケジュールで戻ってきます。

問題は構造にあります。外部のローカライゼーションツールは、継続的インテグレーションパイプラインを実行できません。リンター、ビルド工程、リンクチェッカー、フロントマターのスキーマについても把握していません。翻訳済みのコンテンツをリポジトリへ送り返し、問題が起きないことを期待するだけです。しかし実際に問題が発生すると、チームの誰かが作業を中断し、翻訳ツールが持ち込んだ書式の問題、壊れた構文、無効なマークアップを修正しなければなりません。

大規模言語モデルとエージェント型の体験は、こうしたワークフロー全体を再考する新たな機会をもたらしています。エージェントが翻訳を生成し、チェックを実行してエラーを確認し、出力が有効になるまで再試行する。このような緊密なフィードバックループが、状況を根本から変えます。

ただし、これが機能するのは、コンテンツが本来ある場所、つまりリポジトリ内に留まる場合だけです。外部プラットフォームへ送った瞬間、翻訳は他者のスケジュールで戻ることになり、連携が崩れます。本来なら即時に得られたはずのフィードバックに、数時間または数日を要するようになります。有用性の基盤となっていたコンテキストは、すでに失われています。フィードバックループを失うことで、エージェント型ワークフローがもたらすはずだった利点もすべて失われます。

Glossiaを形作った所見

こうした不満だけから、Glossiaが生まれたわけではありません。このプロジェクトは、開発とローカライゼーションの両方における深い経験から成長しました。それにより、一方の視点だけでは見えにくい問題が明確になりました。言語に関するワークフロー、翻訳チーム内の人間関係、そして既存のツールが現在の形になった理由を理解することが不可欠でした。

私たちは共に、同じ所見へ何度もたどり着きました。ローカライゼーションツールは、大規模言語モデルも、コーディングエージェントも、継続的インテグレーションパイプラインも存在しない世界を前提に設計されていました。そのモデル全体が、翻訳は開発ワークフローの外部で行われ、後から戻されるものだと想定していました。10年前なら合理的でしたが、現在はそうではありません。

そこで私たちは問い始めました。ローカライゼーションエージェントがコーディングエージェントと同じように動作できたらどうなるだろうか。

私たちは、AnthropicがClaudeを用いたエージェント型ワークフローをどのように捉えているかを注意深く見てきました。エージェントにツールへのアクセスを与え、タスクを推論し、自らの出力を検証し、問題があれば反復するというパターンは、ローカライゼーションにも非常によく適合します。翻訳エージェントがソースファイルを読み、プロジェクトのコンテキストを理解し、翻訳を生成し、リンターを実行し、プルリクエストを作成する前に問題を修正する。これは空想ではありません。私たちが構築しているワークフローです。

Glossiaはソフトウェア業界への私たちからの贈り物です

私たちが Glossia を構築したのは、より多くのソフトウェアがローカライズされることを望んでいるからです。減ってほしいからではありません。

複雑なプロセスと高額なプラットフォームは、小規模なチーム、個人開発者、サイドプロジェクトにとって、ローカライズを手の届かないものにしています。翻訳ワークフローに調達プロセス、単語単位の価格交渉、引き継ぎを調整するプロジェクトマネージャーが必要であれば、ほとんどのチームは英語のままリリースして、それで終わりにするでしょう。

Glossia は、すでに利用できるモデルを使用します。また、出力の検証には、私たちのツールではなく、皆様自身のツールを使用します。

私たちは、ローカライズはテストスイートの実行と同じくらい自然であるべきだと考えています。

エージェントを第一に、インターフェースを第二に

Glossia の中核はエージェントです。最も難しい課題が最初に解決される場所であるため、まずはターミナルを主要なインターフェースとしています。具体的には、ソースファイルの読み取り、翻訳の生成、チェックの実行、出力が有効になるまでの反復処理です。これは、OpenAI が Codex で、Anthropic が Claude Code で採用したものと同じパターンです。エージェントを構築し、ターミナルを与え、作業を任せます。

しかし、ターミナルは最初のインターフェースにすぎず、唯一のインターフェースではありません。ローカライズ品質に貢献するすべての人が開発者ではないことは理解しています。私たちは、この点について社内で頻繁に話し合っています。翻訳の正確性、トーン、文化的なニュアンスを最も重視する人々は、多くの場合、ブランチ、コンパイル、JSON を基準に考えることのない言語専門家やコンテンツ専門家です。

そのため、同じエージェントを基盤とした新しいインターフェースを構築したいと考えています。言語専門家がコンテンツ、コンテキスト、翻訳を並べて確認できるようなものです。言語専門家は、どのモデルにも代替できない人間の判断力を提供します。改善が必要な箇所を改善します。そして、コミット、検証、プルリクエストの作成など、それ以外のすべてをエージェントが処理します。

現時点ですべての答えが揃っているわけではありません。それは意図的なものです。本質を捉えていないユーザーインターフェースを急いで作るよりも、慎重に構築したいと考えています。しかし、目指す方向は明確です。Glossia は、ソフトウェアがあらゆる言語で利用できることを大切にするすべての人を受け入れるべきです。

今後の展開にご注目ください

Glossia はまだ初期段階にあり、私たちは開かれた形で開発を進めています。ここで述べた内容に、ローカライズに対する皆様の考え方と共通する点があれば、ぜひこのプロジェクトにご注目ください。今後も進捗を随時お知らせします。