翻訳者もまたエージェントである——AgentKitsが自らのドキュメントをローカライズする方法

多くのオープンソースプロジェクトがまだ手をつけていない領域

オープンソースのドキュメントは、いつの間にか「英語だけ」ではなくなりつつある。GitHubリポジトリを対象にしたある学術調査によると、非英語のドキュメントを含むリポジトリの割合は2015年1月の3.7%から2025年5月には13.0%へと、10年足らずで3倍以上に増えた——その大半の期間、英語のみという前提が疑われることなく標準だったことを踏まえると、これは無視できない変化だ。同じ期間にコード自体にも多言語化の波が及んでおり、2025年にサンプル調査されたJavaファイルの22%以上が非英語のコメントを含み、13%が非英語の文字列リテラルを含んでいた。ローカライズに本気で取り組んだプロジェクトは歴史的に見返りを得てきた——その代表例がWordPressで、ウェブ全体の40%以上を占めるシェアの大きな理由の一つは、「まず英語のドキュメントを読める人」を前提にせず、数十の言語で提供してきたことにある。

それでも、多くの中小規模のオープンソースプロジェクトはローカライズに踏み切れずにいる。理由は単純で、翻訳を最新の状態に保ち続けるコストが高いからだ。毎週のように更新されるREADMEには、毎週更新できる翻訳ワークフローが必要になる。それを外部委託しようとしても、メンテナーが数人しかいないプロジェクトの規模にはスケールしない。AgentKits——20エージェント・77コマンド・28スキルを備えた出荷済みMarketing Kitを中心とする、私たちのオープンソース・MIT ライセンスのAIエージェントキット群——は、この制約を詳しく説明する価値のあるやり方で解決した。自らのドキュメントをエージェントに翻訳させるツールを作り、そのツール自体を別のオープンソースパッケージとして公開したのだ。

実際に動いているもの

このツールはリポジトリ内に scripts/translate-readme として存在し、@anthropic-ai/claude-agent-sdk のストリーミング query() API の上に直接構築された、実際に動作するNode.jsコードだ——一般的な翻訳APIをラップしたものではない。このスクリプトに込められたいくつかのエンジニアリング上の選択は、具体的に取り上げる価値がある。それらこそが、「LLMを呼び出すだけのスクリプト」と、無人で・繰り返し・コストや正確性の問題を起こさずに実際に運用できるパイプラインとの違いだからだ。

まずキャッシュ。すべての原文ドキュメントはSHA-256でコンテンツハッシュ化され、翻訳を実行する前に .translation-cache.json ファイルと照合される。前回の実行以降に英語の原文が変わっていなければ、キャッシュされた翻訳がそのまま再利用され、API呼び出しは一切発生しない。これは見た目以上に重要だ——これがなければ、CIの実行やメンテナンス作業のたびに、変更されていないコンテンツにまでトークンを浪費しながら、すべての言語のすべてのドキュメントをゼロから再翻訳することになる。

次に並行処理。翻訳ジョブは並列実行され、同時実行数は Math.min(languages.length, 10) に制限されている——10言語分の実行を1言語分の翻訳とほぼ同じ時間で終わらせるのに十分な並列度でありながら、同時APIリクエスト数が青天井にならないようにしている。

3つ目は、コストを想定ではなく実測している点だ。スクリプトは各翻訳ジョブについて、SDK自身の result メッセージから直接 total_cost_usd を読み取り、任意で maxBudgetUsd の上限を設定できる。上限に達すると、支出限度を超えて翻訳を続けるのではなく実行を止める仕組みだ。これは、従来の機械翻訳APIのような「文字数に応じた固定単価のAPIリクエスト」としてLLM呼び出しを扱う姿勢とは明確に異なる——文字単位の一律料金には予算の上限は必要ないが、ドキュメントごとにコストが変動しうるモデル呼び出しには必要になる。

4つ目は、技術文書を翻訳する誰にとってもおそらく最も重要な点だが、プロンプトの中でモデルに対し、コードフェンス、ファイルパス、そして /training:start-0-0 のようなスラッシュコマンドには手を触れないよう明示的に指示している。一般的な翻訳APIには「この文字列は読者がそのまま入力すべきコマンドである」という概念自体が存在しない——コードフェンス内のコメントを平気で翻訳したり、CLIのフラグを崩したりしてしまう。プレーンな言葉でコードと地の文の区別を指示されたLLMは、その区別を直接守ることができる。これはまさに、開発者向けコンテンツにおいてLLMによる翻訳が従来型のニューラル機械翻訳とは別のカテゴリのツールになる理由となる、指示追従の能力そのものだ。

同じツールを、23モジュールの講座にも再利用

translate-readme ツールは、単一ファイル向けの使い捨てスクリプトではない。同じ基盤パイプライン(scripts/translate-training として別パッケージ化されている)が、AgentKitsの23モジュールからなるマーケティングトレーニング講座——学習者をキャンペーン戦略へと導きながら、AgentKits自身の製品をケーススタディとして使うインタラクティブなカリキュラム——のために、完全にローカライズされたコマンドツリー一式を生成している。リポジトリのコマンドツリーには、その結果が反映されている:トレーニングパスの完全な言語バリエーションが10個生成されており(commands/training-ar、-de、-es、-fr、-ja、-ko、-pt-br、-ru、-vi、-zh)、それぞれが23モジュールすべてを含む完全なパラレルコピーであり、要約版や部分的なものではない。

言語の選定自体も恣意的ではなく、段階的に設計されており、その理由づけはツール自身のソースコード内にコメントとしてそのまま書き込まれ、ロールアウトの優先順位ごとにグループ分けされている:「Tier 1——迷う余地のない選択」グループ(中国語、日本語、ブラジルポルトガル語、韓国語、スペイン語、ドイツ語、フランス語)は、最大かつ商業的に最も明白な開発者市場を最初に押さえるためのもの、「Tier 2——強い技術コミュニティ」グループ(ヘブライ語、アラビア語、ロシア語、ポーランド語、チェコ語、オランダ語、トルコ語、ウクライナ語)がそれに続き、さらに先のTierも存在する。細かい話ではあるが、実態のある事実だ。ロールアウトは「思いつく限りすべての言語に翻訳する」ではなく、マーケティングエージェント・ツールキットの次のユーザーがどこから来る可能性が高いかについての、明示的で優先順位づけされた賭けだった。

なぜ翻訳APIではなくLLMなのか

同じパイプラインを、LLMではなく従来型のニューラル機械翻訳APIに接続することも技術的には可能だっただろう。だからこそ、このコンテンツに関して言えばそれが誤ったトレードオフになる理由を具体的に述べておく価値がある。2026年のベンチマークデータによれば、LLMは複雑で専門用語の多いコンテンツに関して、COMET評価で従来型のNMTエンジンより8〜15%高いスコアを示している——さらにWMT24の共有タスクでは、まさにその用途向けに特化して構築された専用のニューラル機械翻訳システムを相手に、LLMベースのシステムが11言語ペア中9つで勝利した。この差が生まれる理由は、LLMがより広い文脈をドキュメント全体にわたって読み取り、用語集やトーンの指示をファイル全体を通じて保持し、プレーンな言葉によるフォーマットルールに従うことができるからだ——これはまさに、AgentKits自身のプロンプトが依拠している「このスラッシュコマンドには触れるな」という指示そのものである。

コスト面の話は逆方向に振れており、都合のよい数字だけを引用するのではなく、正直に述べておく価値がある。Microsoft Translatorのような従来型NMT APIは、およそ100万文字あたり10ドルという価格設定で、大量処理においては本当に安価で予測可能な単価を実現している。LLM APIは文字数ではなくトークン数で課金され、モデルの階層によって価格は大きく異なる——DeepSeek V3のようなコスト効率の高い選択肢はおよそ100万入力トークンあたり0.27ドルで動く一方、ニュアンスを重視して構築されたプレミアムモデルはそれよりも明確に高くつく。トレーニングカリキュラム全体を、内容に意味のある変更があるたびに10言語へ翻訳し直すプロジェクトにとって、これはまさにAgentKitsのパイプラインに組み込まれた maxBudgetUsd の上限とSHA-256キャッシュが管理しようとしているトレードオフそのものだ——文脈を理解し指示に従う翻訳のためにプレミアムを払いつつ、その発生量には上限を設け、すでに済んでいる作業はスキップする。

気づく価値のある点

AgentKitsは、他社の製品のためにキャンペーンを立案し、コピーを書き、ファネルを最適化するAIエージェントを中心に据えたMarketing Kitを提供している。そのAgentKitsが、自らのREADMEと自らのトレーニングカリキュラムを10言語に翻訳するために使っているツールは、それ自体がエージェントであり、同じSDKの上に構築され、キット全体が謳っている「モデルにプレーンな言葉で指示を与え、文脈を踏まえて推論させる」というパターンをそのまま踏襲している。これは見過ごしていい偶然ではない。「エージェントにこの作業を確実にやらせよう」という製品の売り文句を掲げるプロジェクトが、自らのドキュメントパイプラインをまさに同じやり方で運用しているという事実は、どんなケーススタディよりも具体的な形の自信の表れであり、しかも検証可能だ——翻訳されたドキュメントと、それを生成したツールの両方が、同じ公開リポジトリの中に置かれているのだから。