複数の地域にわたる電子メールキャンペーンのローカライゼーションは、多くの手動手順で遅く、繰り返しの作業であった。複数のレビュー者は別々のバージョンで作業し、同じコンテンツが複数回書き換えられ、最大13言語で一貫性を管理するには大きな連携が必要でした。 新しいプラットフォームや外部ツールを導入する代わりに、私は内部実験を実行しました。 Could localisation be automated using only the tools already available inside a standard enterprise Microsoft environment? プロトタイプは主にSharePoint、Power Automate、およびTeams に依存しており、Azure OpenAI 経由でアクセスできる GPT-4.1 mini は、コントロールされた QA ステップのために厳密に使用され、LLM ベースの推論の恩恵を受けることができ、すべてのデータを同じエンタープライズ 環境内に保持します。 このワークフローをサポートするために、構造化された SharePoint ライブラリを設定しました。 ローカライフサイクルの各段階を表すフォルダ: Email translations Folder Purpose 01_Incoming_EN Source English files; Power Automate trigger 02_AI_Drafts Auto-translated drafts from Copilot + GPT 03_In_Review Files waiting for regional review 04_Approved Final approved translations 99_Archive Archived or rejected versions 01_Incoming_EN ソース英語ファイル; Power Automate trigger 02_AI_Drafts Copilot + GPT の自動翻訳プロジェクト 03_In_Review 地域見直しを待つファイル 04_Approved 最終承認翻訳 99_Archive アーカイブされたまたは拒否されたバージョン ファイルは、その状態に応じてこれらのフォルダ間で自動的に移動します。 目標は完璧なローカライゼーションシステムを構築することではなく、内部ツールを使用してプロトタイプがどこまで進めるかを見ることでした。 それは繰り返しの仕事の大部分を削除し、より構造化されたレビュープロセスを生み出した。 The Problem: Process, Not Language 問題:言語ではなくプロセス 多くの地域でコンテンツを手動でロケーション化することで、いくつかの一貫した問題が生じました。 各地域は独自のファイルを編集したので、複数の異なるバージョンが同時に存在しました。 ソーステキストが変更されたとき、すべてのリージョンがバージョンを更新しなかったため、不一致のコンテンツが発生しました。 ファイルは異なる場所に保存され、異なる名前で保存され、どのバージョンが現在のものかを特定することは困難でした。 レビューは、特にチームが異なるタイムゾーンにいたときに時間がかかりました。 複数のファイルで同じ編集を繰り返すと、小さなエラーのリスクが高まります。 Attempt 1: Copilot-Only Translation 試み1:コピロットのみの翻訳 Copilot は現在、より新しい GPT-5 シリーズモデルで実行されているが、このプロトタイプは以前のバージョンに基づいて構築され、その翻訳行動はこれらの以前の機能を反映した。 ワークフローの最初のバージョンはシンプルでした: ファイルが 01_Incoming_EN にアップロードされました。 Power Automate triggered automatically. Copilot は各地域の翻訳を生成しました。 SharePoint トリガーは、ファイルのアップロードが終了する前に起動できるため、フローにはファイルサイズの完了チェックが含まれています(ファイルサイズ > 0 まで待つ前に継続してください)。 しかし、主な問題はすぐに明らかになった:コピロットの翻訳は、エンドツーエンドのローカライゼーションのための十分な信頼性がありませんでした。 共通の課題は: CTAs translated too literally (CTAs translated too literally) 言語間で異なるトーンとスタイル メンバーが削除または変更される リスト、スペース、および構造の格式化の違い これにより、コピロットは最初のプロジェクトを作成するためにのみ有用になりました。 第二の品質チェックが必要だった。 Attempt 2: Adding GPT-4.1 Mini for QA 試み2:QAのためのGPT-4.1 Miniの追加 次のバージョンでは、レビューのステップを追加しました: Copilot オリジナル翻訳 GPT-4.1 mini (Azure) → QAおよび一貫性チェック GPT-4.1 mini 改善: トーン一貫性 場所保全 フォーマット 安定 源泉の意味と一致する意味 不要な書き換えを避けるために、プロンプトは調節する必要がありましたが、調整後、出力はワークフローで使用するのに十分に一貫しました。 Engineering Work: Making the Workflow Reliable エンジニアリングワーク:ワークフローを信頼できるようにする アーキテクチャは単純でしたが、実際の使用中にいくつかの問題が発生し、修正が必要でした。 Platform behaviour: SharePoint トリガーは必ずしもすぐに始まらないため、チェックとリトリが追加されました。 チャンネル名が変更されたときにチームのルーティングが失敗したため、マッピングを更新する必要がありました。 Design issues: いくつかの並列のステップは最初の走行で失敗したので、リトリ論理が導入されました。 JSON 応答では時には予想されるフィールドが欠けていたため、検証が追加されました。 ファイル名は不一致であったため、単一の名称形式が定義された。 これらの調整の後、ワークフローは正常な条件下で信頼できるように実行されました。 Final Prototype Architecture 最終プロトタイプアーキテクチャ 以下は、システムの完全な構造です。 1. SharePoint Upload & Intake このプロセスは、ファイルがアップロードされたときに始まりました。 Email translations / 01_Incoming_EN 電源自動化: ファイルが完全にアップロードされたことを確認しました(zero-byte guard) リサイクルメタデータ 抽出テキスト 特定のターゲット地域 SharePoint は、すべての段階の真理の唯一の源として機能しました。 2. Power Automate Orchestration Power Automate は、ワークフローのすべての部分を制御しました。 英語のソースを読む 翻訳プロジェクトのコピロットを呼び出す GPT-4.1 mini for QA にプロジェクトを送信 地域ごとに支店を構築 E-mailing output to local teams(現地チームへの出力) チーム認証カードの発行 「変更を要求する」または「変更を承認する」 承認されたファイルを保存する 04_Approved 03_In_Review で更新されたバージョンを保存する 99_Archive で古いバージョンのアーカイブ すべてのルーティング、リトリ、およびステータス移行は、Power Automateによって処理されました。 3. Copilot Translation Pass Copilot は、抽出したコンテンツを翻訳し、電子メールの構造のほとんど - リスト、スペース、およびフォーマット - を GPT だけよりもよく保存しました。 4. GPT-4.1 Mini QA Pass GPT-4.1 ミニチェック: トーン一貫性 Alignmentの意味 フォーマット 安定 ホーム > Integrity これにより、地域見直しのためのより信頼性の高いプロジェクトが作成されました。 5. Regional Review (Email + Teams) 各エリアで、Power Automate: 電子メールで翻訳されたファイルを送信 Teams Adaptive Card with Approve/Request changes を掲載しました。 変更が提出された場合、更新されたファイルは また、ワークフローに戻りました。 03_In_Review 6. Final Storage 承認された翻訳は、 一貫した名称形式を用いる。 04_Approved 拒否されたまたは時代遅れのバージョンが移行されました。 これにより、完全かつクリーンな監査トラックが確保されました。 99_Archive. Results 結果 実際のワークフローでプロトタイプをテストした後: 翻訳時間は数日から数分に短縮 バージョン紛争が少なくなる 最低限のマニュアル書き換え スピードアップサイクル Microsoft 環境内で処理されるすべてのデータ これは専用ローカライゼーションシステムを置き換えるものではなかったが、繰り返しの手動作業の大幅な量を除去した。 Limitations 制限 いくつかの言語はまだスタイリッシュな調整が必要です。 チームの承認は、レビューの応答時間に依存 the flow needed retry logic for transient errors. 過渡的なエラーのためのリトリ論理 長いまたは複雑なメールにおけるトーン一貫性の変化 これらは、プロトタイプとして受け入れられるものでした。 Next Step: Terminology Memory 次 次の投稿: Terminology Memory 次に計画されている改善は、以下を含むベクトルベースの用語ライブラリです。 Glossary 製品名 restricted terms 地域特有のフレーズ Synonyms グループ トンルール 両方のモデルは、翻訳を生産またはチェックする前にこのライブラリを使用します。 Final Thoughts 最終思考 このプロジェクトは、ローカライゼーションワークフローの多くが標準の Microsoft ツールと Azure でホストされている 1 つの LLM を使用して自動化できるかを理解するための内部実験でした。 これは完全なローカライゼーションプラットフォームではありませんが、既存のエンタープライズスタック内のシンプルで構造化されたワークフローで何が達成できるかを示しています。
