並列AIエージェントで4日間に390万語を翻訳した話
17年分・493本のブログ記事を10言語、約4,900ファイル、約390万語に翻訳しました。Claude Codeの並列エージェントがあったから実現できた話です——ただし、韓国語の大失敗、広東語の「声」の問題、5時間の利用制限が、成功以上に多くのことを教えてくれました。
1ヶ月前、DIALØGUE に48時間で5言語を追加した話を書きました。計画書こそがAI作業の速度の秘訣だという話です。
あのときは、UIの文字列が400個ほどある単一アプリへの5言語追加でした。
今週、もっと大きなことに挑戦しました。ブログ全体——17年分、493本の記事——を10言語に翻訳するというプロジェクトです。ベトナム語、インドネシア語、スペイン語、フランス語、ポルトガル語、ドイツ語、日本語、韓国語、中国語（簡体字）、そして広東語（繁体字）。
約4,900ファイル。約390万語。4日間。
これは「AIは魔法だ」という話ではありません。何千もの翻訳タスクを並列AIエージェントに投げると実際に何が起きるか——うまくいくオーケストレーション、出力を読むまで気づかない失敗、そしてマシンが大量に書くときの品質管理にまつわる、居心地の悪い真実についての話です。
スケールの問題
ぼくのブログは2007年にさかのぼります。シンガポールのサーチマーケティングについて300語でさらっと書いたものもあれば、米中関係や海外移住ガイドについて5,000語で掘り下げたものもある。アーカイブにはYahoo SEM分析から書評、AIプロダクトローンチまで、ありとあらゆるものが含まれています。
493本を9言語にプロで翻訳したら、翻訳チームで何週間、下手すれば何ヶ月もかかる。コストも「ちょっと痛い」では済まなくて、「家を担保に入れる」レベルになりかねません。
ただ、ぼくはすでにi18nインフラを整備していました——next-intlのルーティング、ロケール対応コンポーネント、非英語ページ用のISR——これは広範な国際化の取り組みの一環として構築済みでした。技術スタックは準備できていた。あとはコンテンツだけでした。
1日目：ベトナム語と最初の教訓
ベトナム語から始めたのは、個人的な理由があります——ぼくの母国語だからです。翻訳された記事を読んで、おかしいところがあればすぐにわかる。
Claude Code は1セッションで493本すべてを翻訳しました。プロセスはこんな感じでした：
- 英語のMDXファイルを読む
- コンテンツを翻訳し、フロントマターの構造をそのまま保持する
- URL、コードブロック、技術用語はそのまま残す
- 翻訳済みファイルを
content/blog/vi/YYYY/MM/DD/slug.mdxに書き出す - 「よろしくお願いします、Chandler」に相当するベトナム語の締め言葉を入れる
最初のQAパスで、以降のすべての言語につきまとうことになるパターンが見つかりました：URLと締め言葉です。エージェントがブログの内部URLを「翻訳」してしまう（/blog/2024/... を存在しないベトナム語スラグに変えてしまう）、"Chandler" をベトナム語の名前に置き換える、フロントマターの slug フィールドをまるごと消してしまう、といったことが起きていました。
QAチェックリストを作りました：
- ファイル数がソースと一致している（493本）
- 空ファイルやスタブファイルがない
- すべてのフロントマターに
slug、title、date、categoriesがある - 内部URLが書き換えられていない
- 締め言葉がそのロケールの慣習に合っている
- CJK言語の場合：ネイティブ文字が実際に入っている
このチェックリストが、その後のすべてのロケール作業の骨格になりました。
2日目：並列エージェントのブレークスルー
ベトナム語が完了し、QAチェックリストの効果が証明されたところで、もっと速くやる必要がありました。Claude Code がこの種の作業で圧倒的に強い機能が並列サブエージェントのディスパッチ——複数の独立したエージェントを立ち上げて、それぞれが別のファイルを同時に処理できるのです。
スペイン語でのオーケストレーションはこんな感じでした：
Dispatching 30 translation agents...
├── Agent 1: 2007-2008 posts (42 posts)
├── Agent 2: 2009 posts (38 posts)
├── Agent 3: 2010-2011 posts (35 posts)
├── ...
├── Agent 28: 2025 Nov-Dec posts (12 posts)
├── Agent 29: 2026 Jan posts (8 posts)
└── Agent 30: 2026 Feb posts (9 posts)
各エージェントはバッチの記事と、スタイルガイドと、QAチェックリストと、締め言葉の規則を受け取りました。並列で動き、ファイルを独立して書き出す。各エージェントが別々のファイルを扱うので、調整は不要です。
スペイン語：1セッションで493本翻訳完了。 続いてフランス語。ポルトガル語。ドイツ語。日本語。
約12時間で5言語。これが「未来だ」と感じる部分です——ターミナルに30個の進行状況インジケーターが同時に並んで、各エージェントが夕飯を作っている間に10年分のブログ記事を処理していく光景は、なかなか壮観でした。
広東語（zh-HK）の翻訳セッションが実際にどんな様子だったか——計画から、ディスパッチ、QAまで——のシミュレーションがこちらです：
オーケストレーションのパターン
作業を通じて見えてきたパターン：
- ディレクトリを先に全部作る ——エージェントはターゲットディレクトリが存在しないと、サイレントに失敗します
- 年の範囲でバッチを区切る ——通常の記事は1エージェントあたり10〜15本、3,000語超の記事は2〜3本
- すべてのディスパッチにスタイルガイドを含める ——エージェント間に共有メモリはないので、各エージェントに完全なコンテキストが必要
- ロケールが完了するたびにQAを実施 ——ファイル数、空ファイル、壊れたフロントマター、URLの書き換え、締め言葉の一貫性
- 取りこぼしはターゲットを絞ったクリーンアップエージェントで修正 ——毎回必ず5〜15本は抜けたり壊れたりする
韓国語の大惨事
韓国語は他の7言語と同じパターンのはずでした。エージェントをディスパッチして、待って、QAして、取りこぼしを直す。
でも実際には、どのロケールよりも翻訳品質が最悪でした。
韓国語の記事の72%は翻訳ではなく、要約でした。 エージェントが350本以上の記事を2〜3段落のあらすじに切り詰めていて、細部も個性もニュアンスもすべて失われていました。レイ・ダリオの『Principles』に関する4,000語の分析が200語の概要に。詳細なSEMチュートリアルが「この記事はサーチエンジンマーケティング戦略について論じています」に。
UIの文字列ファイル（messages/ko.json）はさらにひどかった。韓国語と英語が混在していて、"Chandler" が "Ch및ler" のように文字化けしていました。및 は韓国語で「および」という意味の文字——なぜかモデルが単語の途中で置き換えていたのです。
ロケール全体をゼロからやり直しました。全記事。2回目は、内容をすべて保持してソース記事の長さに合わせるよう厳しく指示したところ、きれいに仕上がりました。
教訓：並列実行はミスを増幅させる。 プロンプトに微妙な欠陥があれば、30のエージェントが同じミスを30倍の速さで繰り返します。QAは任意ではない——「完了」と「惨事」の間に立っている唯一のものです。
中国語問題：正しくなるまでに43コミット
中国語（簡体字・zh）は最も手間のかかるロケールでした。品質の問題ではなく——翻訳自体は良かった——43回の個別コミットという数字が、セッションが何度も上限に達したことを物語っています。
Claude Code はAnthropicのAPIで動いていて、利用制限があります。Max tierのSonnet 4.6でも、30の並列エージェントを展開するような長時間セッションは最終的に5時間のクーリングタイムに突入します。中国語の場合、それは波に乗っての翻訳を意味しました：約50本翻訳→上限到達→待つ→続ける→また上限→を繰り返す。
中国語の翻訳はQAも最も念入りに行う必要がありました。CJKコンテンツには固有の失敗パターンがあります：
- 別のスクリプトの文字（日本語の漢字が簡体字に混入）
- ブログではなく政府文書のような過度に堅い文体
- 中国語の句読点の代わりに英語の句読点が使われている（，vs. , と 。vs. .）
- 翻訳すべきでない名前が翻訳されている（「Claude」は中国語でも "Claude" であって、"克劳德" ではない）
広東語の「声」の問題
繁体字・広東語（zh-HK）を追加しようとしたとき、まったく異なる課題に直面しました。翻訳には広東語特有の助詞——嘅（所有格）、咗（過去形）、喺（〜に/で）、啲（いくつか）、冇（持っていない）——を使い、広東語の文章の特徴であるカジュアルで会話的なトーンを維持する必要がありました。
標準的な北京語の翻訳は、香港では官僚的に聞こえます。「本网站提供中文版本」は正しい北京語ですが、広東語話者なら「呢個網站有中文版本」を期待する。同じ意味なのに、まったく違う「声」になる。
課題は翻訳の正確さではなく——声の真正性です。モデルは文法的に正しい広東語を生成できますが、口語的な助詞とコードミキシングのパターンを明示的に指示しない限り、北京語の文体にデフォルトされてしまいます。
広東語のQAチェックでは、すべてのファイルに広東語特有の助詞が入っているかgrepで確認しました。493本中493本がパス。ただし、messages/zh-HK.json のUIの文字列ファイルは最初のバージョンが約70%英語——エージェントが翻訳をほとんどスキップしていたので、全部手動で書き直しました。
OpenAI Codexで試してみたこと
ドイツ語翻訳あたりでClaude Codeの利用制限に達したとき、待ち時間にOpenAIのCodexを試してみることにしました。ChatGPT Plusの無料月間があって、Codexへのアクセスが含まれていました。
良かった点： Codexは計画書をしっかり作ります。コードベースの初期分析と提案された翻訳アプローチは、よく構造化されていて妥当でした。レスポンスも速い。そして指示に忠実に従う——それが長所になることもあります。
悪かった点： 使ったバージョン（gpt-5.2-codex）は並列サブエージェントを実行できませんでした。記事を順番に——一度に1本——処理する。493本では話になりません。また、5〜10本こなすと止まってフィードバックを求める短いスパートで動く。毎回「続けて」と言わないと次のバッチに進まない。
セッション途中でgpt-5.3-codexが利用可能になったので切り替えました。改善はされていましたが、並列実行はやっぱりない。根本的なアーキテクチャの違い——Claude Codeは30以上の独立したエージェントを同時実行できるのに対し、Codexは単一の順次処理プロセスとして動く——が、バルクコンテンツ作業においてClaude Codeを圧倒的に速くしています。
率直な比較： Codexは集中した単一ファイルの作業に向いています。レスポンシブで指示にも忠実。でも、ぼくが必要としていた種類の大量並列実行——9ロケールにわたる4,437ファイル——に関しては、Claude Codeのエージェントアーキテクチャはまったく別の次元にあります。
すべてを救ったチェックリスト
すべてのロケールが同じQAパイプラインを通りました：
✓ File count: 493/493
✓ Empty files: 0
✓ Small files (<100 bytes): 0
✓ Missing slugs: 0
✓ Rewritten URLs: 0
✓ Broken frontmatter: 0
✓ Wrong sign-off: 0
✓ Native characters present: 493/493
CJK言語にはこれを追加：
✓ Cantonese particles (嘅/咗/喺/啲/冇): 493/493
✓ No mixed-script contamination: PASS
✓ Chinese punctuation: PASS
このチェックリストがなければ、韓国語の要約を本番に出していたと思います。70%英語の広東語UIも出していた。存在しない翻訳スラグへのリンクが壊れているブログ記事も出していた。
チェックリストは官僚主義じゃありません。個人では到底読み切れない何千ものファイルを生成する本番パイプラインにおいて、唯一信頼できるQA手段なんです。
最終的な数字
| 言語数 | 11（英語＋10言語の翻訳） |
| 翻訳した記事数 | 493本 × 10言語 = 約4,900ファイル |
| 語数 | 約390万語 |
| 日数 | 4日間（2月24〜27日） |
| UIの文字列ファイル | 10ロケールのJSONファイル（各約475キー） |
| メールテンプレート | 10ロケール |
| ジャーニーデータ | マイルストーンとラーニングパスをJSONBで翻訳 |
| 利用制限に達した回数 | 数えるのをやめた |
| 全ロケールやり直し | 1回（韓国語） |
実際に学んだこと
1. スタイルガイドがすべて。 広東語の声、韓国語の丁寧さのレベル、ポルトガル語の「Abraço」という締め言葉——これらは飾りじゃありません。「翻訳された」と「ローカライズされた」の違いを生むものです。スタイルガイドがなければ、文法的には正しいけど官僚的な文書みたいなコンテンツができあがります。
2. 並列エージェントは力の乗数——そしてリスクの乗数でもある。 30のエージェントが正しく動けば、1時間で1言語が完成する。30のエージェントが同じミスをすれば、350本の切り詰められた記事と全ロールやり直しになる。
3. 規模においてQAは必須。 4,437本の翻訳済み記事を手動でレビューすることはできません。でも、最も一般的な失敗——ファイルの欠落、壊れたフロントマター、書き換えられたURL、間違った締め言葉、切り詰められたコンテンツ——をキャッチする構造的なチェックは自動化できます。
4. 一番難しいのは翻訳ではなく「声」だ。 どのLLMでもテキストを翻訳できます。元の文章を書いた人物らしく聞こえるようにすること——その温かさ、カジュアルさ、知的な好奇心を——9言語と17年分の文体の進化を通じて維持するには、明示的な指示と反復的な調整が必要です。
5. 利用制限は本物の制約。 最高ティアでも、長時間の並列エージェントセッションは制限に達します。中断を計画に入れてください。中断した場所から再開できるように作業を構造化する。
6. 実際の読者でテストする。 ベトナム語の翻訳は自分でQAできました。韓国語や日本語については、構造的なチェックに頼ってモデルを信頼するしかない。それは既知のギャップです。話せない言語で本気で品質を追求するなら、ネイティブの読者にサンプルを確認してもらうべきです。
やる価値があったか？
ぼくのブログは11ロケールで、読者の母国語でコンテンツを届けられるようになりました。ホーチミン市のベトナム人マーケターが、2011年のシンガポールのサーチ市場分析をベトナム語で読める。日本のAI研究者が、Sydneyを構築した2024年の記事を日本語で読める。香港の広東語話者が、翻訳されたコンテンツではなく、自分たちのために書かれたかのようなコンテンツを手にできる。
すべての翻訳が完璧かといえば、そうじゃない。このスケールの機械翻訳には荒削りな部分もあります。うまく伝わらない比喩もある。言葉の置き換えだけでは済まない文化的な参照もある。
でも、代替案は493本の記事が英語のみで、世界のインターネットユーザーの20%程度にしか届かない状態でした。今は60%以上に届いています。
4日間。390万語。インフラは整いました。英語で書く新しい記事は、デプロイプロセスの中で10言語に翻訳されます。
本当の問いは、AI翻訳が完璧かどうかではありません。完璧が、アクセスできることの敵になっているかどうかです。
よろしくお願いします、Chandler
