翻訳がタスクでなくなるとき
最初は単に「もうひとつの言語」です。重複したエントリ。いくつかコピーされたフィールド。誰かがリレーションをダブルチェックし、別の誰かがフォーマットを直します。面倒ですが、対処は可能です。
そのうちコンテンツは増え続けます。
より多くのページ。より多くのコンポーネント。より多くのダイナミックゾーン。同じエントリに触れる人が増えます。突然、翻訳はもはやタスクではなくプロセスになります — そしてそのプロセスは、説明しにくいが感じ取りやすい部分で時間、信頼、整合性を損ない始めます。
さらに悪いのは、技術的には何も壊れていないことです。ページは公開され、コンテンツは存在します。それでも新しいロケールが増えるたびに摩擦が増え、どの更新もリスクを伴うように感じられます。手動の手順は、それ自体が静かに問題を引き起こす可能性のある箇所になります。
ここでチームは通常、ツールやコスト、人員数について議論します。
それは間違った議論です。
本当の問題は言語ではありません。規模です。そして規模はどれだけ注意深くしているかを気にしません — それはシステムにしか反応しません。
このケーススタディは、翻訳を機能やボタンとして扱うのではなく、インフラとして扱ったときに何が起きるかを検証します。
なぜStrapiの組み込みAI翻訳機能を使わないのか？
それは自動化されておらず、大量翻訳のサポートは限定的で、リレーションの設定、ページの公開、画像の処理には依然として手作業が必要です。小規模なチームで10言語以上を管理するようになると、手作業で行うのは現実的でなくなります。
ソリューションアーキテクチャとデータフロー
Strapi CMS向けのカスタム翻訳拡張機能で、翻訳をバックグラウンドジョブとして処理し、リアルタイムの進捗トラッキングを提供します。コンポーネント、ダイナミックゾーン、ブロックなどの複雑なネストされたコンテンツ構造を扱い、HTML、Markdown、URL、プレースホルダー、その他の特殊なフォーマットを保持します。
ジョブのキャンセル、リトライロジック、堅牢なエラー回復にも対応し、モデル選択や翻訳設定の構成を容易に行える洗練された管理UIも提供します。
主な機能
バックグラウンドジョブシステム
翻訳は専用のジョブマネージャーが管理するバックグラウンドジョブとして処理されます。これにより、長時間実行される処理、リアルタイムの進捗追跡、キャンセルやリトライ動作が可能になり、Strapiの管理UIをブロックしません。
スマートなコンテンツ抽出
コンテンツ抽出器はStrapiのエントリ、コンポーネント、ダイナミックゾーンを巡回して翻訳可能なフィールドを特定し、ID、リレーション、メディア参照などの翻訳不可能な構造は保持します。
マルチモデル対応
翻訳ツールは複数のOpenAI GPTモデルをサポートしており、プロジェクトや対象ロケールに応じてコスト、速度、品質のバランスを取れます。
インテリジェントなバッチ処理
フィールドはトークン使用量を効率化しつつレート制限内に収めるためにバッチにまとめられます。このバッチ処理が、24時間以内に1000ページ以上を達成するための鍵です。
翻訳動作設定
管理者は、どれだけ原文に忠実または自由に翻訳するか、ブランド用語を保持するか、プレースホルダ、HTML、Markdownの扱い方を設定できます。
GPTモデルに送るプロンプトは設定可能で、プロジェクトごとに語調、フォーマリティ、ロケール固有の好みを調整できます。
リレーションの取り扱い
システムは翻訳後にエントリ間のリレーションを尊重して再構築するため、ローカライズされたコンテンツも各ロケール間で正しくリンクされたままになります。
スループットと1000ページの見積もり
ページあたり平均50の翻訳可能フィールド、ターゲット言語5言語を仮定すると：
1000ページ × 50フィールド = 翻訳する50,000フィールド
50,000フィールド ÷ バッチサイズ20 = 2,500 APIコール
2,500コール × 平均5秒 = 12,500秒 =
約3.5時間／言語
5言語 × 3.5時間 = 約17.5時間合計
+ オーバーヘッド（抽出、保存、リレーション） = 約20〜24時間今後の展開
コンテンツがある規模に達すると、努力は線形にスケールしなくなります。
10ページでうまくいっていたものが、静かに100ページでは破綻します。1言語では管理可能に感じることが、10言語になると脆弱になります。人々の関心が薄れたからではなく、手作業のプロセスが成長に耐えられないからです。
最も高価な失敗はめったに明白ではありません。それらは、コンテンツを編集することへのためらい、公開への恐れ、あるいはもはや誰も完全には信頼していないワークフローとして現れます。これらの問題が目に見えるころには、通常すでにかなり長く存在していることが多いです。
その気づきが、私たちをここに導きました。
この翻訳システムは製品や機能として始まったのではなく、本番環境での現実的な制約に対応するために生まれました。そして、この問題が特定のチームやプロジェクトだけのものではないことはすぐに明らかになりました。
そこで、私たちはそれを公開します。
システム全体をオープンソース化する準備をしています—デモでも簡略化された例でもなく、このパイプラインを本番で稼働させている実際のインフラストラクチャです。ジョブシステム、コンテンツ処理ロジック、バッチ戦略、保護策――大規模に動作させるためのすべてを含みます。
現在、リポジトリを公開する前にドキュメントを最終調整し、最後の荒削りな箇所を整えています。
公開時期を知りたい、早期アクセスを得たい、あるいはオープンでの進展を追いたい場合は、登録してください。
また、こうしたシステムの構築と運用から得た実践的な教訓も共有します——CMSのスケーリング、本番環境でのAI、チュートリアルには出てこないトレードオフなど。
誇大広告なし。ふわっとした表現なし。実際に機能するものだけ。
それが役に立ちそうなら、やることは分かりますよね。