一つのテキストは、どのように信頼できるウェブページの訳文になるのか？

Chrome の extension service worker はイベント駆動で、アイドル時に終了することがあります。通常の JavaScript グローバル変数は自動保存されません。そのため、このプロジェクトでは翻訳メモリとクォータを IndexedDB に保存し、再接続後にページからアクティブな需要を再宣言できるようにしています。これはライフサイクル設計であり、worker が決して中断しないという意味ではありません。

プラットフォームの根拠：Chrome 公式：service worker lifecycle（2026-10-25 参照）。

バックグラウンドスケジューラーは、最初の非同期メモリ検索を始める前に、「検索中」のジョブをインデックスへ登録します。後から届くページの需要は同じジョブを購読し、先の検索がまだ戻っていなくても、同じタスクを別途作りません。そのため、非同期検索中の重複需要も統合できます。

UTF-16 コード単位は JavaScript の文字列長に使う単位です。emoji は複数の単位を占める場合があり、複数の Unicode コードポイントが、ユーザーに見えるひとつの字形を構成することもあります。書記素（grapheme）は、このような可視のテキスト単位のまとまりを表し、token はモデルのトークナイザーによって決まります。

既定値の 2000 は、各テキスト単位の文字列長の上限です。ひとつの書記素だけで上限を超えたら、入力が大きすぎると報告します。ブラウザーがテキスト分割をサポートしない場合、フォールバックはコードポイント単位で処理するだけなので、複合字形を完全にまとめることは保証できません。

短いセグメントにはローカルのヒューリスティックもあります。URL などのノイズを除いた後、ラテン文字の単語 1 つだけなら省略することがあり、中国語・日本語・韓国語の文字を含む短いセグメントは保持できます。細切れのリクエストを減らす一方、意味のある単語を見落とす可能性もあります。選択テキストの翻訳には、ページ翻訳と同じ短文のしきい値を適用しません。

関連情報：ブラウザーのテキスト分割機能。

設定余白が ≤0 の場合、両側とも 0 を返します。上向きに読む場合は上下の範囲を入れ替えます。スクロール速度は EMA で平滑化します：α=1−exp(−dt/200)、新速度＝旧速度＋（瞬間速度−旧速度）×α。dt の単位は ms、瞬間速度の単位は px/s です。間隔が 400ms に達したら、新しいサンプルをそのまま採用します。

方向転換には、逆方向への移動が累積で max(120px, 0.35H) に達する必要があります。前方向の速度が 2.5 viewport/s に達すると、高速スクロール状態に入り、2 秒間維持できます。これらのしきい値は、わずかな引き戻しによる監視範囲の再構築を減らすものです。設計上のヒューリスティックであり、読む意図を認識するモデルではありません。

まずページ全体の無効化を処理し、次に文全体の原文保持／指定訳文、ユーザーが固定した訳文、外部送信禁止を確認し、最後に語句をプレースホルダーへ置換します。外部送信を禁止しても、ローカルに保存された訳文は表示できます。

Aho–Corasick は複数の語句の検索を担当します。「最左・最長」は、その後の並べ替えとカーソルによる選択が共同で決める結果です。走査は UTF-16 コード単位で行われ、自然言語の単語境界は理解しません。全体の処理には一致候補の展開と並べ替えも含まれるため、全コストを単純に O(n) とは書けません。

照合範囲には任意のテキスト、文全体の厳密一致、リテラルの語句が含まれますが、任意の正規表現には対応していません。コンパイルまたは照合に失敗した場合は、より直接的な参照走査方式にフォールバックできます。

ページ翻訳の意味上の識別情報には、プロバイダーやモデルを直接含めません。他の意味条件が同じなら、モデルを変えても既存の結果にヒットする可能性があります。「強制再翻訳」の場合に初めて翻訳メモリと旧版キャッシュを飛ばし、結果の検証に成功した後、同じセマンティックキーのメモリを置き換えます。

選択テキスト翻訳と翻訳センターは、それぞれ固有の入口の取り決めを使い、翻訳設定にもプロバイダー識別子を含めます。そのため、翻訳センターの A プロバイダーのカードが B プロバイダーのカードの結果を使うことはありません。同じプロバイダー設定でモデルを変更した場合は、元の識別情報を維持します。

コンテキスト、ルール、バージョンも意味上の契約に含め、ハッシュの厳密一致で訳文を探します。異なるページの同じ文でも、他の意味条件まで一致して初めて共有できます。似ているだけの文章が自動的にヒットすることはありません。

同じ翻訳リソースの時間条件には最も遅いしきい値を採用し、枠の解放や書き込み完了も必要なら、対応するイベントを待ちます。異なる候補ジョブの間では、最も早く起動できる可能性のある時刻を探します。固定容量のリング状時間バケットにより、過去のリクエスト数に応じてメモリが無制限に増えるのを防ぎます。分の窓は 62 バケットで各 1 秒、日の窓は 1442 バケットで各 60 秒です。

差し引きが属する時間バケットの番号は ceil（帰属時刻 ÷ 各バケットの長さ）、つまり切り上げで求めます。永続化スナップショットの作成時には、コミット待ちの差し引きの帰属時刻を、少なくとも現在時刻＋1000ms に設定します。トランザクション完了後にも現在時刻より前でないことを確保し、保守的に期限を決めます。リクエストのトークンバケットは整数で計数し、1 回のリクエストは 1,000,000 マイクロ単位に相当します。これはモデルが文章を分割する token とは無関係です。

複数の翻訳リソースが使える場合、まず「候補窓内の互換性のある需要量 ÷ 利用可能な同時実行数」を比較し、分母は少なくとも 1 とします。次に負荷、ルーティング優先度、安定したリソース識別子順を比較します。これは目の前の候補からリソースを選ぶヒューリスティックであり、グローバルな最適配分を求めるものではありません。

これはローカルでディスパッチ可否を決めるための推定です。プロバイダーの実際の token 分割とは異なる場合があり、アカウントの残り枠の代わりにもなりません。ページのバッチでは翻訳指示とコンテキストも推定に加えるため、原文の文字数だけを毎分の token 使用量とみなすことはできません。

適応的な同時実行数の調整は既定で無効です。有効にすると、同時実行上限はハード上限の半分を切り上げた値から始まります。成功応答が届き、統計窓が 20 秒に達していれば、前の窓で成功が少なくとも 10 回あり、未処理ジョブが残り、輻輳がなかったかを確認します。すべて満たした場合にのみ枠を 1 つ増やします。容量の輻輳時は半減し、同じ調整周期内の減少は最大 1 回です。自動フォールバック切り替えも既定で無効であり、明示的に有効にした場合のみ、条件に合えば別のリソースへ切り替えます。

パーサーは、指定マーカーで囲まれた先頭の思考部分、および応答全体を囲み、言語指定がないか JSON と指定された Markdown フェンスを許容します。正しい空白やデータフィールドの順序変更も受け入れます。任意の文章から JSON を推測して抜き出すことはしません。大きなストリーミング増分は 32,768 UTF-16 単位のチャンクに分けて処理し、チャンクをまたいでテキスト、エスケープ、Unicode の解析状態を保持します。

製品の方向性は「原文を自動判定 → 台湾の繁体字中国語」です。ページ翻訳と共有設定では異なる繁体字中国語の言語タグを使い、Microsoft ではさらに ISO 言語対応表で変換し、対応が見つからなければ繁体字中国語のタグを使います。サービス間の連携では、この言語表現の違いを処理する必要があります。

システムプロンプトは、原文とコンテキスト内の指示を無視し、訳文にはプレーンテキストを使うよう求めます。これは期待する動作を表しますが、プロンプトインジェクションや誤訳を完全に排除できる保証はありません。DeepSeek の思考モードは既定で無効で、ユーザーが変更することもできます。

表示タイミングの制御器は、順次届く結果を統合し、直近の処理時間でタイミングを調整します。新コスト推定値 = 0.6 × 旧コスト推定値 + 0.4 × 今回の所要時間。次の間隔は min（1000ms，2 × 新コスト推定値）です。ブラウザーのアニメーションフレーム通知がまだ届かない場合は、250ms のタイマーが補います。ここで追跡するのは処理時間であり、ブラウザーのレイアウトと描画の全コストを表すものではありません。

同じブロックには最新の更新待ち計画だけを保持し、延期する計画は最大 128 件です。超えた場合は「再更新が必要」の印に切り替えられ、この印の上限は 4096 です。ページ変更後の再照合は、段落ごとに実行中のジョブ 1 つと再実行待ちの印 1 つにまとめます。

表示用の要約値は「テキスト長＋32 ビット FNV-1a ハッシュ」で書き換えを省略できるかを判断し、バックグラウンドの SHA-256 による意味上の識別とは異なります。内容が異なっても同じ要約値になる可能性があります。複数文の訳文は元の翻訳単位の順番で組み合わせ、接合部は中国語・日本語・韓国語の空白規則から推定します。元の空白を一文字ずつ復元するわけではありません。

同じ元ノードを保持することは、既存のオブジェクト関係の維持に役立ちます。ただしイベントのバインディング、レイアウト、操作の動作は、サイト自体の構造や更新方法の影響を受けます。

待機中または保存失敗後の内容の保持期間は 10 分で、後続のキュー操作や再試行時に確認してクリーンアップします。容量は「原文の UTF-8 バイト数＋訳文の UTF-8 バイト数 × 2＋1024」で推定し、実際のメモリ使用量とは異なる場合があります。キューが満杯になると新たなページ翻訳のディスパッチを一時停止しますが、送信済みのリクエストは完了できます。

このキューは実行中のメモリにのみ存在します。バックグラウンドサービスが終了すると、書き込み未完了の内容は再起動しても自動復元されません。図はページ翻訳の保存状態を示しています。対話型の入口は内容を保存ジョブに入れるだけで、同じ完全な画面状態フローを待つことはありません。

通常のジョブの遅延再試行にはフルジッターを使い、毎回ゼロから待機上限までのランダムな遅延を選びます。容量関連の HTTP 429 では、制限されたリソースまたはクォータ範囲にクールダウンを設定し、サーバー指定の待機時間を使います。指定がなければ基本遅延を使い、ランダムジッターは適用しません。

ジッターは再試行の時刻を分散させます。応答ヘッダー Retry-After が指定する時刻は追加の下限であり、秒数または HTTP 日付を受け付け、サーバーとの時刻差も考慮します。サーバーが要求する待機時間は最大 7 日まで保持します。

起動スケジュールは、最も早い期限のタイマー 1 つにまとめます。予想待機時間が 30 秒以上なら、ブラウザーのバックグラウンドアラームで起動を補います。時計の確認では、システム時計と単調時計の経過時間を比較します。ずれが 5 秒を超える、またはシステム時刻が 5 秒を超えて戻った場合、新たなディスパッチを一時停止します。新たな異常がなく安定期間が 2 秒に達して初めて、保守的な方針で再開します。

キャンセル図が示すのは送信済みのネットワーク試行です。枠を予約済みでも未送信の試行は、先に終了して枠を解放できます。ただし、進行中の差し引きトランザクションがその後コミットに成功した場合、実際にサービスを呼び出していなくても保守的な差し引きは残ります。終了を確認できないネットワーク操作では関連リソースを隔離し、遅れて終了通知を受け取るまで枠を保持します。バックグラウンドサービスの再起動では新しい実行世代を作り、旧リクエストは同時実行枠を占有しなくなりますが、既知のクォータ台帳は保持し続けます。