目次
ほとんどのAI translation toolは同じパターンに従います：テキストを貼り付けて、翻訳を取得する。それは素早いメールには機能しますが、複数の言語、ブランド用語のグロッサリー、そしてリリース前に変更をレビューする必要のあるチームを持つプロダクションアプリケーションで何千もの翻訳キーを管理している場合は機能しません。
私たちはBetter i18nのAIシステムを異なる方法で構築しました。シンプルな翻訳APIの代わりに、23の専門ツールを持つ会話型Agent、すべての書き込み操作に対するHuman-in-the-Loop承認、そして実際の翻訳管理ワークフローのために設計されたアーキテクチャを作成しました。
この記事では、その背後にあるエンジニアリングを詳しく説明します。
なぜAgentなのか、翻訳APIではなく？
典型的な機械翻訳レビューワークフローは次のようなものです：文字列をエクスポートし、翻訳サービスに送り、結果を受け取り、インポートし、手動でレビューし、問題を修正し、再エクスポートする。これは遅く、エラーが起きやすく、翻訳を正確にするコンテキストから翻訳プロセスを切り離します。
Agentベースのアプローチはこのモデルを根本的に変えます。ファイルを操作する代わりに、AIはプロジェクトに直接操作します — キーを読み取り、グロッサリーを理解し、同期設定を確認し、リアルタイムで承認できる変更を提案します。
重要な洞察は、翻訳管理は単一のタスクではないということです。プロジェクトの状態を読み取り、判断を下し、変更を実行し、結果を確認するワークフローです。複数のツールを持つAgentはこれを自然に処理します。翻訳APIはそうではありません。
23ツールのアーキテクチャ
Agentは、非常に異なる権限モデルを持つ2つのカテゴリに分けられた23の専用ツールにアクセスできます。
読み取りツール：完全な自律性
10のツールがAgentにプロジェクトへの読み取りアクセスを与えます。これらはデータを変更できないため、承認なしに自動的に実行されます：
- getTranslations — キー、Namespace、言語、ステータスでフィルタリングして翻訳を取得します
- getKeyDetails — コンテキストノート、タグ、言語ごとのステータスを含む個別キーのメタデータを取得します
- getLanguages — 完了率とともに設定された言語を一覧表示します
- getProjectStats — プロジェクト全体のメトリクスを返します：総キー数、言語数、翻訳カバレッジ
- getDoctorReport — 不足している翻訳、未使用キー、複数形の問題、用語の不一致を特定する診断を実行します
- getSyncs と getSyncDetails — GitHub/GitLab同期統合とその最近のアクティビティを検査します
- getContentModels と getContentEntries — CMSコンテンツ構造とエントリを閲覧します
- createPlan — Agentが複数のステップを調整する必要がある場合に実行計画を生成します
Agentはこれらのツールを使って、変更を提案する前にコンテキストを構築します。「フランス語に欠けているキーをすべて翻訳して」と尋ねると、AgentはまずgetTranslationsを呼び出してどのキーが欠けているかを正確に特定し、次にgetProjectStatsを呼び出してスコープを理解してから、単一のターゲットを絞った提案を生成します。
書き込みツール：Human-in-the-Loop承認
11のツールがプロジェクトデータを変更できます。それぞれが実行前に明示的な人間の承認を必要とします。これがAI翻訳品質へのアプローチの核心です — AIが提案し、人間が決定します。
翻訳ツール：
- proposeTranslations — ターゲット言語で欠けているキーの新しい翻訳を生成します
- proposeTranslationEdits — コンテキスト、グロッサリー、またはフィードバックに基づいて既存の翻訳の改善を提案します
- translateBatch — 単一の操作で複数の言語にわたる複数のキーを処理します
キー管理ツール：
- proposeKeys — コードベース分析に基づいて新しい翻訳キーを提案します
- proposeDeleteKeys — 未使用または重複したキーを特定し、クリーンアップを提案します
言語管理ツール：
- proposeLanguages — プロジェクトのニーズに基づいて追加する新しい言語を推奨します
- proposeLanguageEdits — 言語の表示名、フォールバックチェーン、または設定を変更します
パブリッシングツール：
- publishChanges — 承認された翻訳をCDNにプッシュするか、GitHub PRをトリガーします
コンテンツ管理ツール：
- proposeContentEntries — CMSコンテンツエントリを作成または更新します
- proposeContentModel — コンテンツモデルのスキーマ変更を提案します
- proposePublishEntries — コンテンツエントリをパブリッシングのためにキューに入れます
Human-in-the-Loop：承認フローのエンジニアリング
「Human-in-the-Loop」という用語はAIマーケティングでよく使われます。私たちのシステムで実際にどのように機能するかを説明します。
書き込みツールが呼び出されると、Agentはそれを直接実行しません。代わりに、何が変わるかを正確に示す構造化されたdiffである提案を生成します。提案はチャットインターフェースにレビュー可能なアーティファクトとして表示されます。
翻訳提案では、次のことが確認できます：
- ベース言語のソース文字列
- ターゲット言語での提案された翻訳
- 適用されたグロッサリー用語
- 信頼性コンテキスト（これはシンプルなUIラベルですか、それとも複雑なマーケティング文章ですか？）
次の3つのオプションがあります：
- すべて承認 — ワンクリックですべての提案された変更を受け入れる
- 選択的承認 — 一部の翻訳を受け入れ、他を拒否する
- 変更を要求 — Agentに何を修正するかを伝え、改訂された提案を生成する
書き込み操作は承認後にのみ実行されます。これは「確認/キャンセル」ダイアログではありません — 検査、編集、反復ができる本物のレビューステップです。
なぜこれがAI翻訳品質にとって重要か
機械翻訳レビューはほとんどのローカリゼーションワークフローのボトルネックです。チームはレビューをスキップするか（エラーをリリースする）、すべてを手動でレビューするか（ゆっくり進む）のいずれかです。私たちのHITLアプローチは中間点を見つけます：
- AIが単純な翻訳の80%を処理します
- 人間は判断が必要な20%にレビュー努力を集中します
- すべての翻訳に明確な出所があります：AI生成、人間レビュー済み、または人間編集済み
- 監査証跡が誰が何を承認したかを記録し、コンプライアンスを簡単にします
プログレッシブレンダリング：ストリーミング翻訳テーブル
Agentがキーのバッチに対して翻訳を生成すると、結果は一度にすべて表示されません。翻訳テーブルはチャットインターフェースに段階的にストリーミングされます — 各行はその翻訳が完了するとレンダリングされます。
これはユーザーエクスペリエンスによって駆動されるエンジニアリングの選択です。6つの言語にわたって150のキーを翻訳する場合、それは900の個別の翻訳です。何かを表示する前に900すべてが完了するのを待つことは、数分間ローディングスピナーを見つめることを意味します。プログレッシブレンダリングにより、最初の結果を直ちにレビューし始めることができます。
実装はserver-sent eventsを使用してツール結果をチャットインターフェースにストリーミングします。フロントエンドは、行が到着するにつれて追加するミュータブルな翻訳テーブルコンポーネントを管理します。
コンテキスト管理：地に足をつけたまま
大規模言語モデルは長い会話でコンテキストを失う傾向があります。私たちは3つのメカニズムでこれに対処します：
30秒プロジェクトコンテキストキャッシュ
Agentがプロジェクトデータを読み取ると、結果は30秒間キャッシュされます。Agentがマルチステップ操作中にプロジェクトの状態を複数回参照する必要がある場合、冗長なAPI呼び出しを行う代わりにキャッシュにアクセスします。これはレイテンシを低減し、Agentが複雑なワークフロー中に一貫性のない状態を見ることを防ぎます。
コンテキストの削減（slimToolResults）
Better i18n APIからのツールレスポンスは大きくなる可能性があります — 2,000のキーと12の言語を持つプロジェクトは相当なペイロードを生成します。slimToolResultsシステムは、ツールレスポンスから非必須データが会話コンテキストに入る前に自動的に削除します。
例えば、AgentがgetTranslationsを呼び出すと、完全なレスポンスには作成タイムスタンプ、バージョンID、ユーザー帰属などのメタデータが含まれます。slimToolResultsパスはAgentが必要とするデータのみを保持します：キー名、ソース文字列、翻訳。これによりトークン使用量が大幅に削減され、コンテキストウィンドウのオーバーフローが防止されます。
50ステップ会話制限
各会話は最大50のAgentステップ（ツール呼び出し）をサポートします。これは複雑なワークフローに十分です — Namespace全体を翻訳し、結果をレビューし、編集を行い、パブリッシュする — 一方で暴走ループを防ぎます。ステップカウンターはUIに表示されるため、残りのキャパシティを常に把握できます。
チャット履歴：デュアルストレージアーキテクチャ
Agentの会話は2つの場所に同時に保存されます：
- IndexedDB（ブラウザローカル） — ダッシュボードに戻るときにネットワーク遅延なしで会話を即座にロードします
- Postgres（サーバーサイド） — すべてのAgentインタラクションの永続的で検索可能な監査証跡を維持します
デュアルストレージアプローチは2つの競合する要件を解決します。開発者は最近の会話への即時アクセスを望みます（IndexedDBはサブミリ秒の読み取りを提供します）。チームはコンプライアンスと知識共有のための監査証跡が必要です（Postgresは耐久性のある、クエリ可能なストレージを提供します）。
AIチャットを開くと、会話はIndexedDBから即座にロードされます。Postgresのコピーはバックグラウンドで同期し、ローカルストレージがクリアされた場合の信頼できる情報源として機能します。
実際のワークフロー：プロダクションアプリに韓国語を追加する
Agentが実際のタスクをどのように処理するかの具体的な例を示します。
ステップ1：あなたが尋ねます — 「プロジェクトに韓国語を追加する必要があります。commonとsettings Namespaceのすべてを翻訳してください。」
ステップ2：Agentが読み取ります — getLanguagesを呼び出し（韓国語が設定されていないことを確認）、common NamespaceのgetTranslationsを呼び出し（89のキーを発見）、settings NamespaceのgetTranslationsを呼び出します（34のキーを発見）。合計：翻訳する123のキー。
ステップ3：Agentが言語の追加を提案します — プロジェクトに韓国語（ko）を追加するためにproposeLanguagesを呼び出します。提案が表示され、承認します。
ステップ4：Agentがバッチで翻訳します — common Namespaceに対してtranslateBatchを呼び出し、次にsettings Namespaceに対して呼び出します。翻訳はチャットに段階的にストリーミングされます。英語のソース文字列の隣に韓国語の翻訳が表示されるのが見えます。
ステップ5：あなたがレビューします — 翻訳を確認し、カジュアルなアプリUIに対して過度に丁寧なレジスターを使用している2つを指摘し、Agentに調整するよう伝えます。
ステップ6：Agentが修正します — フィードバックとともにproposeTranslationEditsを呼び出し、指摘された2つの文字列に対して改訂された翻訳を生成します。承認します。
ステップ7：あなたがパブリッシュします — Agentにパブリッシュするよう伝え、publishChangesを呼び出すと、韓国語の翻訳がCDNでライブになります。
合計時間：123の翻訳に約10分、レビューとパブリッシュ済み。Agentなしでは、このワークフローは通常、エクスポート-翻訳-インポート-レビューのサイクルに数時間かかります。
構築しないことを選んだもの
制限事項についての透明性は、機能ドキュメントと同様に重要です。
- 独自の翻訳エンジンなし — 基盤となるモデルとしてGoogle Geminiを使用しています。カスタムの「ニューラル翻訳エンジン」や独自AIは主張しません。
- 翻訳の自動A/Bテストなし — モデルはあなたが選びます。複数のモデルの出力を比較するフレームワークはありません。
- Translation Memoryなし — TMファジーマッチングではなく、グロッサリーベースの用語一貫性を使用しています。TMが必要な場合、Better i18nは今日適切なツールではありません。
- 保証された精度メトリクスなし — AI翻訳品質は言語ペアとコンテンツタイプによって異なります。すべてのカスタマー向けコンテンツに対して人間によるレビューを推奨しています。これがまさにHITLがすべての書き込み操作に組み込まれている理由です。
試してみましょう
AI AgentはすべてのBetter i18nプランで利用できます。ダッシュボードを開き、チャットアイコンをクリックして、シンプルなものから始めましょう：「このプロジェクトの翻訳ステータスを表示してください。」
そこから、実際のタスクを試してください。不足している翻訳を見つけ、生成し、承認プロセスを案内するよう求めてください。Agentは会話的に探索されるように設計されています — ツール名やAPIエンドポイントを暗記する必要はありません。
