AIとMicrosoftツールのみを使用して13言語のメールワークフローを自動化した方法

複数の地域にわたるメールキャンペーンのローカライズは、以前は多くの手動ステップを伴う遅く、反復的な作業でした。複数のレビュアーが別々のバージョンで作業し、同じコンテンツが何度も書き直され、最大13言語にわたる一貫性の管理には大きな調整が必要でした。

新しいプラットフォームや外部ツールを導入する代わりに、社内実験を行いました： 標準的な企業向けMicrosoft環境内ですでに利用可能なツールのみを使用して、ローカライゼーションを自動化できるでしょうか？

このプロトタイプは主にSharePoint、Power Automate、およびTeamsに依存し、追加コンポーネントとして - Azure OpenAIを通じてアクセスするGPT-4.1 mini - を厳密に管理されたQAステップに使用しました。これにより、すべてのデータを同じ企業環境内に保ちながら、LLMベースの推論からプロセスが恩恵を受けることができました。

このワークフローをサポートするために、ローカライゼーションのライフサイクルの各段階を表すフォルダを持つ構造化されたSharePointライブラリEmail translationsを設定しました：

| フォルダ | 目的 | |----|----| | 01IncomingEN | 英語ソースファイル；Power Automateトリガー | | 02AIDrafts | Copilot + GPTからの自動翻訳ドラフト | | 03InReview | 地域レビュー待ちのファイル | | 04Approved | 最終承認された翻訳 | | 99Archive | アーカイブまたは拒否されたバージョン |

ファイルは状態に応じてこれらのフォルダ間を自動的に移動しました。

目標は完璧なローカライゼーションシステムを構築することではなく、内部ツールを使用してプロトタイプがどこまで進められるかを確認することだけでした。

結果として、反復作業の大部分を削減し、はるかに構造化されたレビュープロセスを作成することができました。

問題点：言語ではなくプロセス

多くの地域にわたってコンテンツを手動でローカライズすると、いくつかの一貫した問題が発生しました：

• 各地域が独自のファイルを編集するため、同時に複数の異なるバージョンが存在していました。
• ソーステキストが変更されても、すべての地域がバージョンを更新するわけではなく、コンテンツの不一致につながりました。
• ファイルが異なる場所や異なる名前で保存されていたため、どのバージョンが最新かを特定するのが困難でした。
• 特にチームが異なるタイムゾーンにある場合、レビューに時間がかかりました。
• 多くのファイルで同じ編集を繰り返すと、小さなミスのリスクが高まりました

試み1：Copilotのみの翻訳

現在Copilotはより新しいGPT-5シリーズモデルで動作していますが、このプロトタイプは以前のバージョンで構築されており、翻訳の動作はそれらの初期の機能を反映していました。

ワークフローの最初のバージョンはシンプルでした：

1. ファイルが01IncomingENにアップロードされました。
2. Power Automateが自動的にトリガーされました。
3. Copilotが各地域の翻訳を生成しました。

SharePointトリガーはファイルのアップロードが完了する前に発火する可能性があるため、フローにはファイルサイズの完了チェック（続行する前にサイズが0より大きくなるまで待機）が含まれていました。

しかし、主な問題はすぐに明らかになりました：Copilotの翻訳はエンドツーエンドのローカライゼーションには十分に信頼できるものではありませんでした。

一般的な問題には以下が含まれていました：

• CTAが文字通りに翻訳されすぎる
• 言語間でトーンとスタイルが異なる
• プレースホルダーが削除または変更される
• リスト、間隔、構造のフォーマットの違い

これにより、Copilotは最初のドラフトを生成するためにのみ有用でした。 二次的な品質チェック層が必要でした。

試み2：QAのためのGPT-4.1 Miniの追加

次のバージョンではレビューステップが追加されました：

1. Copilot → 初期翻訳
2. GPT-4.1 mini（Azure） → QAと一貫性チェック

GPT-4.1 miniは以下を改善しました：

• トーンの一貫性
• プレースホルダーの保存
• フォーマットの安定性
• ソースの意味との整合性

不必要な書き直しを避けるためにプロンプトの調整が必要でしたが、調整後、出力はワークフローで使用するのに十分一貫したものになりました。

エンジニアリング作業：ワークフローの信頼性向上

アーキテクチャはシンプルでしたが、実際の使用中にいくつかの問題が発生し、修正が必要でした。

プラットフォームの動作：

• SharePointトリガーは常にすぐに開始されるわけではなかったため、チェックとリトライが追加されました。
• チャンネルの名前が変更されるとTeamsのルーティングが失敗したため、マッピングを更新する必要がありました。

設計上の問題：

• 一部の並列ステップが最初の実行で失敗したため、リトライロジックが導入されました。
• JSONレスポンスに期待されるフィールドが欠けていることがあったため、検証が追加されました。
• ファイル名に一貫性がなかったため、単一の命名形式が定義されました。

これらの調整後、ワークフローは通常の条件下で確実に実行されるようになりました。

---

最終プロトタイプアーキテクチャ

以下はシステムの完全な動作構造です。

1. SharePointアップロード＆取り込み

プロセスはEmail translations / 01IncomingENにファイルがアップロードされたときに開始されました

Power Automateはその後：

• ファイルが完全にアップロードされたことを確認（ゼロバイトガード）
• メタデータを取得
• テキストを抽出
• ターゲット地域を特定

SharePointはすべての段階で単一の信頼できる情報源として機能しました。

---

2. Power Automateオーケストレーション

Power Automateはワークフローのあらゆる部分を制御しました：

• 英語ソースの読み取り
• ドラフト翻訳のためのCopilotの呼び出し
• QAのためにドラフトをGPT-4.1 miniに送信
• 地域ごとのブランチの作成
• ローカルチームへの出力のメール送信
• Teamsの承認カードの投稿
• 「承認」または「変更リクエスト」のキャプチャ
• 承認されたファイルを04_Approvedに保存
• 更新されたバージョンを03InReviewに保存
• 古いバージョンを99_Archiveにアーカイブ

すべてのルーティング、リトライ、状態遷移はPower Automateによって処理されました。

---

3. Copilot翻訳パス

Copilotは抽出されたコンテンツを翻訳し、GPT単独よりもメールの構造 - リスト、間隔、フォーマット - のほとんどを保持しました。

---

4. GPT-4.1 Mini QAパス

GPT-4.1 miniは以下をチェックしました：

• トーンの一貫性
• 意味の整合性
• フォーマットの安定性
• プレースホルダーの整合性

これにより、地域レビューのためのより信頼性の高いドラフトが作成されました。

---

5. 地域レビュー（メール + Teams）

各地域について、Power Automateは：

• 翻訳されたファイルをメールで送信
• 承認 / 変更リクエストを含むTeamsのアダプティブカードを投稿

変更が提出された場合、更新されたファイルは03InReviewに戻り、ワークフローに再度入りました。

---

6. 最終ストレージ

承認された翻訳は一貫した命名形式を使用して04_Approvedに保存されました。

拒否または古いバージョンは99_Archiveに移動されました。これにより、完全でクリーンな監査証跡が確保されました。

---

結果

実際のワークフローでプロトタイプをテストした後：

• 翻訳時間が日単位から分単位に短縮
• バージョン競合の減少
• 手動での書き直しの最小化
• レビューサイクルの高速化
• すべてのデータがMicrosoft環境内で処理

これは専用のローカライゼーションシステムに取って代わるものではありませんでしたが、反復的な手動作業の大部分を削減しました。

制限事項

• 一部の言語ではまだスタイルの調整が必要
• Teamsの承認はレビュアーの応答時間に依存
• 一時的なエラーに対するリトライロジックがフローに必要
• 長文や複雑なメールではトーンの一貫性にばらつきがあった

これらはプロトタイプとしては許容できるものでした。