Scribeは、メール署名をシンプルにし、かつ効果を測定可能にするプロダクトです。企業は従業員ごとの設定なしで、全社で一貫したブランドに沿った署名を展開でき、署名そのものを測定可能な収益チャネルへ変えられます。創業から5年、同社は強いプロダクト・マーケット・フィットを築いていました。プロダクトの全面リビルドにあわせて、Scribeは製品全体とドキュメントを16言語でリリース。統合にかかったのは1日足らずで、その後は採用も代理店も使わず、創業者2人だけでローカライゼーションを運用しました。用語集、ブランドボイス、ロケールごとの指示、さらに各翻訳を採点するAI評価まで含むエンジンを、Lingo.devのMCP serverを通じてClaudeとやり取りしながら構成していったのです。

"Lingo.devは、API、MCP、CLIから自社スタック内でそのまま動かせるローカライゼーションエンジンを提供してくれました。エンジニアリングファーストなチームにとっては、迷う余地のない選択です。"

Clément Champau、CEO兼共同創業者、Scribe

創業5年で、なぜ今ローカライズしたのか#

AIによって、2人チームでもローカライゼーションが現実的になりました。そしてそのタイミングは、プロダクトの全面リビルド――新しいUI、新しいUX、そして16言語対応を打ち出す絶好の節目――とも重なっていました。5年を経て、Scribeは強いプロダクト・マーケット・フィットと安定したUIを手にしていたため、インターフェースの頻繁な変更で再翻訳が振り回される状況でもなかったのです。

市場側の追い風もありました。エンタープライズの買い手の中には、まだAI導入以前にデジタル化を進めている企業もあり、いくつかの市場では、現地の言語で使えないプロダクトは営業プロセス上の摩擦になります。Scribeが最初に狙ったのは、すでに売上のある市場でした。フランス語圏アフリカを含むフランス語、ラテンアメリカ重視のスペイン語、そして英語です。この3言語で、西側世界の大半に加えてラテンアメリカまでカバーできます。そこからさらに、GDPの高い市場――スイス、ノルウェー、スウェーデン――へ広げていきました。"ヨーロッパでも、世界でも、GDPが高い市場ですからね"とClémentは話します。

決め手になったのは、エンジニアリングファーストなプラットフォームだったこと#

ClémentがLingo.devを見つけたのはY Combinatorのディレクトリでした。彼は新しいYCツールを常にチェックし、早い段階で導入するタイプです。最終的な決め手になったのは、そのプラットフォームがスタックのどこに位置しているかでした。Lingo.devはローカライゼーションエンジニアリングプラットフォームです。用語集、ブランドボイス、ロケールごとの指示、そして出力を独立して評価するAI評価を備えた、設定可能なローカライゼーションエンジンであり、API、MCP server、CLIで動きます。開発プロセスの最初のレイヤーで機能し、チームがほかのインフラを扱うのと同じ感覚で運用できます。

"私たちが欲しかったのは、開発プロセスのいちばん最初のレイヤーにあるものです。APIが必要で、MCPも必要です。それさえ揃っていれば、そういうレゴのような部品をエージェントのワークフローに簡単に組み込めます。"

Scribeの共同創業者兼CTOであるGilはAPIドキュメントを読み、十分に信頼できると判断して、すべてを1日足らずで統合しました。

"Gilに送ったら、彼はAPIドキュメントを読んで『ちゃんとしている』と言い、そのまま1日足らずで全部実装してくれました。"

CEOがMCP経由でエンジン全体を構成した方法#

1日で統合した後、Clémentは開発者ではないにもかかわらず、Lingo.devのMCP serverを通じてブランドボイス、用語集、ロケールごとの指示まで、エンジン全体を自ら構成しました。完成した設定はかなりの規模で、16種類のブランドボイス、133件の指示、644件の用語集項目に及びました。

進め方はきわめて具体的でした。まず1言語だけ流し、アプリを開いてスクリーンショットを撮り、それをMCP経由で返す。ここはCTAが崩れた、ここはUIがおかしい、と伝える。するとClaudeが、用語集、指示、ブランドボイスという3つのレバーを調整し、出力が安定するまで詰めていく。その後にフル翻訳を回し、残りの言語も展開していきました。

"1言語だけ実行してアプリを見て、スクリーンショットを撮ってMCP経由で返すんです。ここはCTAが崩れた、ここはUIが崩れた、と。するとClaudeが用語集、指示、ブランドボイスを調整して、正しくなるまで合わせてくれました。"

同じワークフローの中で、エージェントは自律的にも動きました。リビルドしたホームページのSEOを最適化していた際、ClaudeはGoogleがローカライズ済みページを独立したロケール向けページではなく、英語ページのフォールバックとして扱っていることを指摘。エンジンへのMCPアクセスがあったため、修正のためにLingo.dev syncを再実行しました。

自分たちが話せない言語の翻訳品質を、どう検証するか#

このエンジンは、自身の出力を自ら測定します。Scribeの実行全体では、AI評価の平均スコアは100点満点中およそ87点。スコアが付いた翻訳の約96%が70点以上でした。創業者2人が自分では読めない16言語にまたがって品質を把握できる、そのシグナルになっています。

Scribeはおよそ95%の完成度で出し、事業拡大にあわせて残りの差分を埋める手段として、人手によるポストエディットを位置づけています。考え方はシンプルです。本当に課題を解決するプロダクトなら、翻訳が完璧に磨き込まれていなくても、それだけでユーザーが離れることはないということです。

"95%でも十分使えます。本当に課題を解決していて、ユーザーがその解決策を求めているなら、完璧じゃない翻訳が原因でプロダクトを使わなくなることはありません。"

ローカライゼーションは、自社で作るべきか買うべきか#

Clémentは、すでにローカライゼーションを内製していたCTOでもある投資家の1人にLingo.devを勧めました。その反応が、作るべきか買うべきかという問いに答えを出しました。

"Lingo.devを、CTOでもある投資家の1人に勧めました。彼はローカライゼーションを内製していたのですが、返ってきたのは『まさにこれを使うべきだった』という反応でした。『知っていたら投資していたよ』とも言っていました。"

Scribeが意外だったと感じたコストは、初期構築ではありません。維持です。次々に現れて終わりのないエッジケース、そしてシステムをどう改善していくかという継続的な意思決定こそが重かったのです。

"簡単なことなんて何もありません。エッジケースを扱い始めると――しかもそれは次から次へと出てきます――維持には本当に時間がかかります。エンジニアリングファーストなものを組み込んで、裏で常に改善を続けているチームがいるとわかっている方がいいんです。"

AIが実作業をこなすようになるほど、価値はシステムを設計する側へ移ります。用語集、ブランドボイス、指示、そしてAI評価から成るローカライゼーションエンジンは、納期に追われる内製チームが同じ水準で設計できるとは限らないアーキテクチャです。

請求まわりの摩擦と、その改善#

初期段階では、コストの見え方が十分ではありませんでした。Clémentは、実行の途中でクレジットが切れないか確認するためにジョブを開始し、画面を更新し続ける必要がありました。実際にクレジットが尽きるとジョブは止まり、再実行が必要になっていたのです。彼がその課題を伝えると、改善はその週のうちに反映されました。実行前のコスト見積もりと、自動トップアップの利用状況インジケーターです。

"今では、始める前にどれくらい時間がかかるか、いくらかかるかがわかります。以前は、クレジットが途中で切れないように実行を開始して、何度も更新し続けるしかありませんでした。切れたら全部止まって、やり直しだったので。"

この変更によって、実行前に所要時間とコストを把握し、結果を見通せるようになりました。彼が対比していたのは、要望を出して待たされる体験と、要望した改善がその週のうちに反映される体験です。"この反復の速さは素晴らしい"と彼は話していました。

現在の運用状況#

Scribeは現在、Webアプリ、デスクトップアプリなど4つのアプリに加え、ドキュメントも、すべて英語を起点に単一のローカライゼーションエンジンで運用しています。今のところautosyncはオフで、Gilが大きなプッシュのあとに手動で実行しています。これは初期のクレジット問題から続く習慣であり、大きなリリース後に変更が少なかったこともあって定着しました。完全に安定した段階でautosyncをオンにし、1回のプッシュで全アプリとドキュメントへデプロイできるようにするのが計画です。

MCP serverは、APIやCLIと並ぶ、このプラットフォームへの3つの入口の1つです。多くのMCPは読み取り専用だったり、コンテキストに制約があったりしますが、Lingo.devのMCPなら、非開発者でもローカライゼーションエンジン全体を構成できます。そのおかげでGilは、1日でセットアップを終えたあと、すぐ次の仕事に移れました。

"インターフェースにそこまで時間をかけたわけじゃないのに、ちゃんとできました。"

翻訳を担ったのはエンジンで、構成を担ったのはClémentでした。

小規模チームがソフトウェアをローカライズするうえで、これが意味すること#

Scribeの展開は、メール署名管理の枠を超えて通用するパターンを示しています。エンジニアリングファーストなチームにとって、ローカライゼーションは人手の問題からシステム設計の問題へ移りました。翻訳そのものはモデルが担い、残る仕事は、それらを統制するエンジン――用語集、ブランドボイス、ロケールごとの指示、そして出力を採点するAI評価――を構成することです。

この変化は、作るか買うかの判断基準も変えます。内製ローカライゼーションで本当にコストがかかるのは、最初のバージョンではありません。維持です。エッジケース、モデルの変化、そして時間とともに積み上がるロケールごとのルールです。ローカライゼーションエンジニアリングプラットフォームはそこを引き受けるからこそ、2人チームでもローカライゼーション専任の採用なしで16言語を運用できます。

これが他のチームにも当てはまるのは、3つの条件が揃っているからです。ソースコンテンツがバージョン管理下にあること。エンジンがAPI、CLI、MCP serverで動き、すでに使っているワークフローに組み込めること。そしてAI評価によって、チームの誰も話せない言語でも出力を測定できること――翻訳をただ信じるのではなく、検証できるという違いです。

本人たちの言葉で#

"AIがここまでうまく実行してくれる今、価値があるのはアーキテクトの側です。勝つのは、最も優れたシステム設計者です。もし自分で作っていたら、ここまで良いシステムは設計できなかったと思います。"

"Lingo.devを、CTOでもある投資家の1人に勧めました。彼はローカライゼーションを内製していたのですが、返ってきたのは『まさにこれを使うべきだった』という反応でした。『知っていたら投資していたよ』とも言っていました。"

"まずは参入したい市場向けに、1言語だけ回してみてください。実装して、MCPを試してみるといいです。あれが自分で仕事を進めてくれます。いちばんの『なるほど』は、やはりMCPですね。"

Clément Champau、CEO兼共同創業者、Scribe

Scribeは、何千もの企業が全社で統一されたブランド準拠のメール署名を展開するために利用しているメール署名プラットフォームです。従業員ごとの設定は不要で、メール署名を効果測定可能な収益チャネルへと変えられます。2人の創業者が、16言語にまたがるプロダクトとドキュメントを、他のインフラと同じ感覚で運用できる単一のローカライゼーションエンジンとして構築・管理しています。彼らのローカライゼーションはLingo.dev上で動いています。

よくある質問#

ローカライゼーションエンジンの導入にはどれくらい時間がかかりますか？

1日もかかりません。ScribeのCTOはAPIドキュメントを読み、十分に信頼できると判断したうえで、既存のエージェントワークフローにLingo.dev APIを1日足らずで組み込みました。その後、エンジンの設定――用語集、ブランドボイス、ロケールごとの指示――は、CEOがMCPサーバー経由で別途進めました。

開発者でなくてもローカライゼーションエンジンを設定できますか？

はい。1日で導入を終えたあと、ScribeのCEOは、技術への理解はあるものの開発者ではない立場で、Lingo.devのMCPサーバーを通じてエンジン全体を自ら設定しました。まず1言語で動かし、アプリをレビューしながら、出力が安定するまでClaudeに用語集、指示、ブランドボイスを調整させたのです。最終的に完成した設定は、16のブランドボイス、133の指示、644の用語集用語にまで広がりました。

自分で話せない言語の翻訳品質は、どう検証するのですか？

ScribeはAIによる品質スコアリングを活用しています。すべての翻訳は、生成に使ったモデルとは独立した別のモデルによって採点されます。Scribeの実行全体では、平均スコアは100点中およそ87点で、約96％の翻訳が70点以上でした。これにより、2人のチームでも、自分たちでは読めない16言語に対して測定可能な品質シグナルを持つことができ、最後の仕上げに必要な差分だけを人手でポストエディットできます。

ローカライゼーションは自社で構築すべきですか、それとも導入すべきですか？

Scribeの2人の創業者は技術者で、ローカライゼーションを内製することもできました。それでも彼らが選んだのはプラットフォームでした。比較したのは初期開発の負荷ではなく、その先の運用・保守です。実際に内製した経験を持つ、CTOでもある投資家の1人は率直にこう言いました。『まさに、これこそ自分たちが使うべきだったものだ』と。時間とともに積み上がるコストは最初のバージョンではなく、エッジケースやロケールごとのルールへの対応なのです。

ローカライゼーションエンジニアは実際に何をするのですか？

翻訳することよりも、設定することのほうが中心です。Scribeでは、翻訳者やファイルを管理するのではなく、エンジン――用語集、ブランドボイス、ロケールごとの指示――を整え、AIによる品質スコアを見ながら調整していくことが主な仕事でした。この役割はベンダー調整よりもプラットフォームエンジニアリングに近く、翻訳する人を管理するのではなく、翻訳を生み出すシステムを設計し運用する仕事です。

導入を検討している同業者には、何と伝えますか？

「参入したい市場に向けて、まずは1つの言語で走らせてみてください。実装して、MCPを試してみるといいです。MCPがちゃんと仕事をしてくれます。いちばんの『なるほど』は、やっぱりMCPですね。」