Laurelは、プロフェッショナルサービス業界向けのワークインテリジェンスプラットフォームです。企業はLaurelを使ってタイムキーピングを自動化し、収益性を左右する要因を把握し、AI投資のROIを示しています。少し前まで、このプロダクトは英語のみでした。今では、北欧言語、フランス語、オランダ語、ポルトガル語、スペイン語、韓国語を含む12以上の言語で展開されており、中国語（標準語）、タイ語、アラビア語、日本語、ベトナム語もパイプラインに入っています。

Laurelの導入はスムーズで、作業の大半はLaurel側で既存の文字列を抽出・整理し、コードベースを整えることでした。自前で構築する場合は、4〜6か月分のエンジニアリング工数が必要で、その後も保守が継続的に発生すると見積もられていました。さらに、取りこぼすはずだった案件まで含めて考えると、導入しない場合の総コストは、導入コストのおよそ10倍になるとわかりました。今では新しい言語の追加は1日で完了し、プロダクトマネージャーが1人で進められます。18か月前なら、そんな話は信じがたいものでした。

"Lingo.devは私たちの課題を素早く理解し、的確な解決策を示してくれました。ローカライゼーション基盤を自前で構築する必要はなく、そこは彼らが完璧に解決してくれたんです。エンタープライズ向けの価格設定も妥当でしたし、彼らのエンジニアとは共有のSlackチャンネルでつながっています。エッジケースへの対応も数時間単位です。"

— Nick Bazley, Staff Product Manager, Laurel

SaaS企業はいつローカライゼーションに投資すべきか#

Nick BazleyはLaurelのStaff Product Managerで、この6年間、同社のグローバル展開に伴うプロダクトチームを率いてきました。ローカライゼーションについては、実際に動き出す1年ほど前から検討していたといいます。

"いつかは必要になるとわかっていました" とNickは話します。"問題は、いつやるかです。この話題が出るたびに結論は同じでした。超大型プロジェクトになる、ものすごく時間がかかる、しかもアウトプットの品質も完全には見通せない――そんな認識でした。"

Laurelは成長を続け、中堅企業向けからグローバルエンタープライズへと顧客層を広げていました。そこで、あるパターンが見えてきました。まず1つの地域で顧客を獲得し、価値を証明する。すると次に、その顧客が他地域へも展開したいと言い出すのです。

営業チームがヨーロッパ各地で採用を進め、カスタマーサクセスが展開要望を受けるようになるなかで、Nickはこの課題がいずれ表面化すると見ていました。

"この取り組みが必要になった当時、私たちは約50人の会社でした。ローカライゼーション基盤を自分たちで構築するのは相当大きな負担です。チームの半分が何か月も取られかねませんし、その一方で顧客のためにまだまだ作るべきものがたくさんありました。"

なぜローカライゼーション基盤は自作ではなく導入すべきなのか#

Laurelの前には、導入するか、自作するかという2つの選択肢がありました。自作は複数四半期にまたがる取り組みになる可能性が高く、社内見積もりでも超大型プロジェクト、つまり4〜6か月分のエンジニアリング工数が必要とされていました。"自前のローカライゼーション基盤を構築するコスト、時間、労力を抱えるのは賢明ではありません。私たちの成長フェーズにいた事業にとって合理的だったのは、市場で最良のソリューションを導入し、そのぶんコアプラットフォームの構築に集中することでした。"

この議論で最終判断を左右したのは、4つのポイントでした。市場投入までのスピード、ローンチ後のスケーラビリティ、カスタマイズ性、そして品質です。

"私たちはローカライゼーション基盤の専門家ではありません。品質がどうなるかもわからない。ローカライゼーションエンジニアリングを軸に事業を築いてきた会社があるのに、なぜそのリスクを取るのでしょうか。"

ローカライゼーションプラットフォームと従来型TMSをどう評価するか#

NickはPerplexity Proで手早く市場を調べ、上位の検索結果からある従来型TMSを見つけました。さらにGoogle検索でいくつかの候補を洗い出し、LaurelのHead of Engineeringも独自にLingo.devを見つけていました。

彼はその両方を並行して評価しました。

"その従来型TMSは、表面的にはとても洗練されていて、しっかりした会社に見えました" とNickは言います。"でも、実際に中身を見ていき、相手が持っているものと私たちが必要としているものを照らし合わせると、私たちが目指していたスピードと品質を実現できる選択肢は1つしかありませんでした。"

"私がよかったと感じたのは、Lingo.devの向き合い方です。私たちの課題や、やろうとしていることを理解し、そこに対する解決策を出してくれました。エンタープライズ向けの価格設定も妥当でした。そして、スピードと品質の約束が大きな決め手でした。特に印象的だったのは、アクセスのしやすさです。私たちは、実際にそのプラットフォームを作っているエンジニアと共有のSlackチャンネルでつながっています。エッジケースにぶつかっても、返答は数時間です。まるで自分たちの組織の一部のように感じるほどです。"

法律・会計用語におけるAIローカライゼーションの精度はどれほど高いのか#

Laurelのユーザーは法律・会計の専門職です。ドイツ語UIで「billing rate」や「matter」に誤った語が使われていれば、見た目の問題にとどまらず、プロダクト全体への信頼を損ねます。法律・会計の用語は、正確でなければなりません。

Nickは実際の顧客とともに品質を検証しました。最初の検証先は北欧の顧客とフランスの顧客です。北欧チームからのフィードバックはゼロ。フランスの顧客はネイティブスピーカーでしたが、見つかった不正確さは2件だけで、チームはすぐにそれを用語集へ追加しました。それ以降、オランダ語、ポルトガル語、スペイン語などでは問題は発生していません。

私たちは6か月にわたり、12言語でネイティブスピーカーの顧客と一緒に品質を検証しました。報告された用語上の問題は合計2件で、いずれも同日に用語集への追加で解決しています。その結果、用語集を設定したローカライゼーションエンジンのほうが、翻訳ロジックをゼロから構築するよりも、法律・会計用語の一貫性を高く保てることがわかりました。なぜなら、エンジンはあらゆる言語ペアにまたがって用語を同時に適用できる一方、手作業のプロセスではそれを保証できないからです。

"ここしばらく、用語集を調整するために手を入れ直す必要はありませんでした" とNickは言います。

SaaSプロダクトに新しい言語を追加するのに、どれくらい時間がかかるのか#

以前は、カスタマーサクセスマネージャーが顧客からUIのポルトガル語対応が必要だと上げると、その要望はロードマップに入り、優先順位が付けられ、スプリント待ちになり、完了まで数週間かかっていました。

今では、Nickがチケットを作成し、過去の言語追加チケットをテンプレートとして参照し、AI Toolingに渡して待つだけです。するとツール側が設定に言語を追加し、言語切替UIを更新し、PRを作成します。エンジニアがPRをレビューしてマージすれば、その後の継続的なローカライゼーションはLingo.devが自動で回してくれます。

"1日というのは、エンドツーエンドでの話です。チケットを書き始めてからPRが完成するまでですね。だからといって、その1日ずっと自分が手を動かしているわけではありません。ほとんどの時間は別の仕事をしています。"

AIコーディングツールとLingo.devのローカライゼーション基盤があれば、Nickはエンジニアリングの工数をほとんど使わずに新しい言語を追加できます。

"Lingo.devがあれば、今では社内の誰でも新しい言語を追加できるし、私たちのローカライゼーションエンジンも調整できます。これは本当にすごいことです。"

ローカライゼーションのスピードは、エンタープライズ案件の進み方にどう影響するのか#

このビジネスケースは、エンジニアリング時間の節約だけの話ではありません。もちろんそれも実現できます。でも本質は、変化する展開機会に素早く対応できるようにすることです。

"エンタープライズ顧客では、展開のチャンスが突然やってくることがあります" とNickは言います。"新しい拠点で成果が出始めると、こちらがその言語でプロダクトを素早く提供できるなら、すぐにでも展開したいと考えるんです。成長を続けるには、そのスピードにきちんと応えられなければいけません。"

Laurelは最初のヨーロッパ展開を支えるために、フランス語に加えて5つの北欧言語から始めました。その後は、営業とカスタマーサクセス主導でポルトガル語、スペイン語、オランダ語などの要望が生まれ、今ではグローバル拠点への展開に伴って、さらに多くの言語について話し合いが進んでいます。

私たちが数えてみたところ、導入後6か月のあいだに、Laurelは顧客の展開要望に応じて7言語を追加していました。どれも1日未満で完了しています。これを自前構築モデルでやっていたら、この7言語だけで約28回分のエンジニアリングスプリントを消費していた計算です。そのキャパシティは、代わりにコアプロダクト機能へ振り向けられました。

ローカライゼーション基盤は構築すべきか、導入すべきか#

同じような会社――エンタープライズB2Bで、専門職ユーザーを抱え、グローバル展開を進めていて、エンジニアリングチームにも本来取り組むべきプロダクト開発がある会社――のVP Productに何と伝えるかと聞かれると、Nickはまったく迷いません。

"私なら100%ベンダーを選びます。"

自分たちで構築するときに見誤りがちなのは、"複雑さと品質です。品質がどうなるかはわかりません。なぜそのリスクを取るのでしょうか。"

一方で、ベンダー選定でやりがちなのは、自分たちの課題を十分に明確化しないまま選んでしまうことです。"自分たちが解決しようとしている問題を本当に理解し、その特定の課題に合ったベンダーを選ぶこと――そこが決定的に重要です。"

最初に検証すべきなのは、"スピードと市場投入までの時間です。そして初期設定が終わったら、次はスピードとスケーラビリティです。"

待つことの本当のコスト#

初期設定の大部分はLaurel側の作業で、技術スタックを整えることでした。その後は、1言語あたり1日。エンジニアリングスプリントも不要で、ロードマップの調整もいりません。

もう一方の選択肢は、構築に3〜4か月分のエンジニアリング工数がかかり、その後も保守がずっと続き、しかもチームの誰も話せない言語では品質を保証できないというものでした。

Nickはこう端的に言います。"ローカライゼーション基盤は、終わったら次に進める類いのプロジェクトではありません。継続的なものです。事業がスケールするたびに、新しい市場に入るたびに、新機能を追加するたびに関わってきます。簡単である必要があるんです。必要なものを届けるたびに、またエンジニアリングに戻って次のスプリントをお願いするようなことはしたくありません。"

新市場への展開を進めるプロダクトチームにとって、これが意味すること#

Laurelの経験は、グローバルなエンタープライズ需要を抱えるB2B SaaS企業に共通するパターンをよく表しています。ローカライズは、単なる機能要望ではなく、成長を左右する制約へと変わります。問うべきは「ローカライズすべきか？」ではなく、「次の市場にどれだけ早く『対応できます』と言えるか？」なのです。

Laurelのアプローチを決めた要因は3つありました。まず、チームにはコアプロダクトではないインフラにエンジニアリングのリソースを割く余裕がありませんでした。さらに、法務・会計領域の用語品質は、感覚ではなく検証可能である必要がありました。

ローカライゼーションエンジニアリングでは、言語対応をエンジニアリングプロジェクトではなく、設定レイヤーとして捉えます。プロダクトマネージャーは、スプリントを組むことなく、エンジニアの工数を確保することも、翻訳ベンダーと調整することもなく、新しい言語を追加できます。市場拡大のスピードが売上成長を左右するチームにとって、この運用の転換は、機会をものにするか、目の前で逃すかを分ける違いです。

Laurelは、法務・会計の専門家向けAIを提供しています。すでに12以上の言語でプロダクトを展開しており、新しい言語も1日で追加できます。そのローカライズ基盤を支えているのがLingo.devです。

よくある質問#

SaaSプロダクトに新しい言語を追加するのに、どれくらい時間がかかりますか？

Laurelでは、新しい言語の追加をエンドツーエンドでおよそ1日で完了しています。プロダクトマネージャーが過去の言語追加を参照したチケットを作成し、それをAIコーディングエージェントに渡し、最後にエンジニアがPRをレビューします。専用スプリントも、ベンダー調整も必要ありません。以前の選択肢だったローカライズ基盤の内製では、どの言語もリリースできるようになるまでに4〜6か月かかる見込みでした。

スタートアップはローカライズ基盤を構築すべきですか？ それとも導入すべきですか？

LaurelのStaff PMであるNick Bazleyは、内製と導入を比較検討しました。彼の結論はこうです。「私たちはローカライズ基盤の専門家ではありません。品質がどうなるかもわかりません。ローカライゼーションエンジニアリングを軸に事業そのものを築いている会社があるのに、なぜそのリスクを取るのでしょうか？」 内製の見積もりは、エンジニアリングチームの半分を数か月にわたって占有するXXL級のプロジェクトでした。

専門用語に対するAIローカライズの精度は、どれくらい高いですか？

Laurelは6か月にわたり、法務・会計分野のネイティブ話者の顧客とともに12言語で検証を行いました。用語上の問題は合計2件のみで、どちらも用語集への追加によって当日中に解決しました。ローカライゼーションエンジンは、すべての言語ペアで用語集の一貫性を同時に担保します。これは、手作業で構築した仕組みではスケール時に保証できない点です。

ローカライズのスピードは、エンタープライズ営業のセールスサイクルにどう影響しますか？

Laurelの経験では、新しい言語対応を求めるエンタープライズ顧客が期待するのは、数か月後の返答ではなく、数日以内の回答です。Nick Bazleyはその状況をこう表現しています。「チャンスはいつまでも残っているわけではありません。1週間以内に対応できなければ、その機会の窓は閉じてしまうかもしれません。」 ローカライズ基盤に切り替えて以降、Laurelは6か月で7言語を追加し、いずれも1日未満で完了しました。

ローカライズの構築と導入では、コストはどう違いますか？

Laurelの比較では、短い統合期間と継続的な従量課金に対して、内製では4〜6か月分のエンジニアリング工数に加え、終わりの見えない保守と、保証できない品質まで背負う必要がありました。6か月で追加した7言語は、内製モデルなら約28回分のエンジニアリングスプリントを消費していた計算です。そのリソースは、本来コアプロダクトの機能開発に充てられるべきものでした。