Cal.comのミッションは、オープンソースのスケジューリング基盤を通じて2031年までに10億人をつなぐことです。その実現には、あらゆる言語のユーザーに対応する必要があります。しかし長年にわたり、それがエンジニアリングのスピードを鈍らせる大きな足かせになっていました。

課題：いつも追いつかない#

Cal.comは定番のアプローチを一通り試してきました。翻訳管理システム経由でのクラウドソーシング翻訳、ローカライゼーション代理店の活用。どれもコストと調整の負担は増えるのに、結果は同じでした。最優先の言語でさえ、常に最新状態を保てなかったのです。

「国際化対応はいつも後手に回っていました」と、エンジニアリング責任者のKeith Williamsは振り返ります。「代理店への投資や翻訳管理システムを通じたクラウドソーシングを行っても、主要言語ですら同期が取れていませんでした。コストは高く、手作業の負担でエンジニアは機能開発に集中できませんでした。」

この構図は珍しくありません。従来のローカライゼーションプラットフォームが管理しているのは人手による翻訳ワークフローであって、調整のオーバーヘッドそのものをなくしているわけではなく、整理しているにすぎません。リリースのたびに外部チームへの引き継ぎが発生し、待ち時間が生まれ、さらにレビューが重なります。エンジニアリングチームは1日で機能をリリースできても、ローカライズには2週間かかることもありました。

転換点：インフラとしてのローカライゼーション#

2025年、Cal.comはLingo.devにローカライゼーションエンジンを導入しました。ローカライゼーションエンジンとは、状態を持つ翻訳APIです。Cal.comのプロダクト用語、スケジューリング領域の語彙、ロケールごとの設定を、あらゆる翻訳リクエストをまたいで保持します。エンジンが英語の文字列内で「Workspace」や「Booking」に出会うと、モデルが1トークンも生成する前に、用語集がロケールごとに適切な用語を確定します。

導入にあたっては、Cal.comのオープンソースのコードベースとコントリビューターコミュニティに合わせたいくつかの初期調整が必要でした。Lingo.devのチームはその対応を直接進めました。

「彼らのレスポンスの速さは驚異的でした」とWilliamsは話します。「調整が必要になったときも、これまで接してきたどのベンダーより速く修正を届けてくれました。」

成果#

ローカライゼーションエンジンの設定が完了すると、Cal.comはそれをCI/CDパイプラインに接続しました。コードをプッシュするたびにエンジンが起動し、36言語すべての翻訳が自動で更新されます。

• エンジニアリングチームが翻訳ワークフローを管理する必要がなくなった
• 36言語すべてがリリースのたびに同期された状態を維持
• 代理店費用と比べてローカライゼーションコストを大幅に削減
• 引き継ぎゼロ — 翻訳はコードのデプロイと同じパイプライン内で行われる

「いちばん大きいのは、エンジニアがもうローカライゼーションのことを考えなくていいことです」とKeithは説明します。「機能を作れば、翻訳は自動で反映されます。Cal.comを世界中の誰もが使えるものにするために、まさに必要だった仕組みです。」

次の展開#

Cal.comは現在、メールテンプレートにもローカライゼーションエンジンの適用範囲を広げています。そこが、翻訳を別管理している最後の領域だからです。これが完了すれば、プロダクト内のあらゆるユーザー向け文字列が、同じローカライゼーション基盤を通ることになります。

10億のつながりを目指すチームにとって、積み重なる効果は重要です。今日設定したすべての用語集の用語が、今後の新機能、新しいリリース、新たなロケールのすべてで一貫して正しく適用されます。