公式ドキュメントをAIで翻訳するサービスを作った

ベトナムで法人ニート

2年半前、ハノイで起業した。ベトナムでは、外国人は日本ほど気軽に会社登記できないが、起業できてしまえば、IT優遇で、創業から5年は法人税がゼロ。10年までは減税の特典がある。ただし、従来型のソフトウェア受託開発会社は、日本のクライアント相手ではもはや利益がでないのと、他様々な理由であまりおすすめはしない。私は試してみたいビジネスモデルがあったので、2年ほど検証してみた。簡単に言えば、極限まで固定費を抑え、開発はとことん仕組み化を進めた。検証の結果として、私のビジネスモデルはワークし、受託案件は、ミーティングの参加と、コロコロ変わる仕様をソフトウェアに”設定”する程度となり、コストがかからなくなった。税務当局から、コストが低すぎると何度も指摘され、説明すると設定は開発とは言えないので課税するぞと言われる程度には、仕組み化は成功した。

一方で、エンジニア的には、設定は開発とは呼べず、面白くない。飽きちゃった。激しい円安で日本のクライアントのお財布事情が怪しくなってきた頃に、頃合いを見計らって案件を全て手放し、法人ニートとなった。起業時に資本を入れたいと数名の投資家からオファーをいただいたが、全部断って良かった。やりたいことだけやって生きて行きたい。

ニートは時間だけはたくさんあるので、開発のワクワク感を得るべく YouTube 等に入り浸り、”やってみた”を繰り返していった結果、OSS の公式ドキュメントを AI で翻訳するサービスが出来上がったので公開した。

Lang x Lang: 話す言語 x プログラミング言語。

ドキュメント読め

言わずもがなではあるが、OSS の公式ドキュメントの多くは英語で書かれており、非英語圏のエンジニアには熟読のハードルが高い。エンジニアを名乗るくらいなら、英語読め！というのは、そうなのだが、実際そんなに簡単ではない。前職で、普段私とは英語でコミュニケーションしているベトナム人エンジニア数十名程度にアンケートを取ったところ、（自称）英語ドキュメント読めますは、2割程度で、欧米系の外資で長く働いていたマネージャークラスとあとちょっとくらいだった。そういう人材は少ないし、給料も高い。

案件を進めると、利用しているフレームワーク等の OSS に備わっている機能を使わず、独自実装して、結果バグを仕込むエンジニアは想像より遥かにたくさんいるので、実装前にドキュメントを読ませたいのだけど、コードを書きたくて仕方ない彼らには、英語のドキュメントを読むのは苦行であり、モチベーションが下がってしまう。給料の高いマネージャーに、読めば書いてあるようなことを指導させるのも、なんだかな。だ。

経験上、ドキュメント読み込んだジュニア・エンジニアとドキュメント読んでないシニア・エンジニアでは、前者の方がパフォーマンスが高い。これは、ベトナムとか日本とか関係なく、英語ネイティブのエンジニアでも同様だ。

さて、税務当局からケチがつく程度に効率化するには、利用するソフトウェアを熟知している必要がある。あとはビジネス。うちのメンバーが熟知していると言えるかは微妙な気もするが、案件始めにドキュメントを読み込む習慣付けと、そのハードを下げ、私の代わりに仕組み化できる人材を育てたいと思った。

というわけで、公式ドキュメントの翻訳が必要だった。

翻訳の壁

金かかりすぎ問題

OSSの の公式ドキュメントは

• （フルスタックフレームワークとかだと）ボリュームがやばい
• アクティブなOSSの場合、更新速度が速い
• テクニカル過ぎて、普通の翻訳じゃない

という訳で、時間とコストが猛烈にかかる。人力で全て翻訳し、維持し続けるのは現実的とは言えない。それに尽きる。私も自腹でそこまで社会貢献したいとは思っていない。エンジニアが個別に Google 翻訳とか DeepL で翻訳しているのだろうけど、私がこれまでに食べたパンの数を覚えてないのと同様、Google や DeepL は何度も同じ文章を翻訳しており、ハッキリ言って資源の無駄だ。

AI 雑すぎ問題

Chat GPT 等の生成 AI 以前は、DeepL や Google 翻訳などが、一般的な機械翻訳の唯一の手段だったが、

• DeepL の精度はかなり良い。でも対応言語が限られてる
• Google 翻訳の場合、対応言語は豊富だが、読めたもんじゃない（ことが多くある）

という訳で、これ！というツールは、存在しなかった。ベトナム語の場合、某有名企業が作った有料の翻訳ツールが存在するが、Google 翻訳よりはマシかも？程度だった。

Chat GPT や Claude などの生成 AI を使った翻訳には、現時点では大きく3つの問題がある

• 意訳する
• 勝手にとばす
• 必要ないものまで翻訳する

なんとなく意味が分かれば良い程度であれば、1つ目、2つ目は許容できるが、3つ目をされるとかなり読みにくくなってしまう。良い例えがぱっと出てこないが、例えば usability という単語があった場合に、翻訳せず usability もしくは ユーザビリティ として欲しい。使いやすさ と翻訳されると、意味は分かるが、コンテキストを強要する文章になってしまうし、意味もなんだかボンヤリしてしまう。（実際に遭遇したことはないが）token を 象徴 などと翻訳されると、は？となってしまう。IT 系の文章に限らず、テクニカル・タームは、そのまま使ってもらった方が良い。

日本語の翻訳がまぁまぁ良いのは、「カタカナ英語」というスペシャルなユーティリティ・プレーヤーがいるからで、そんなものは、他の言語にはない。知らんけど。

マニュアルの翻訳と同様、技術ドキュメントの翻訳は、全体からすればニッチなので、対応しづらい、対応に時間がかかるのは、AI でも同じようだし、予算もつきづらい。ニッチなら勝負もしやすい。

問題点が明確であれば、対応は簡単だ。賢いのは AI ではなく、あなた。

• 意訳しないで
• 飛ばさないで
• この単語は翻訳しないで

と指示すれば良い。極めて明確な指示であり、間違いようがない。そうとしか取れないプロンプトを作成すれば良い。

のだが、喧嘩売ってるとしか思えないほど無視してくる。たくさんやってると、ドンドン雑になってくる。人間だったら絶対採用しないような困ったちゃんである。ステップ・バイ・ステップの指示（提出前に要件満たしてるか見直して）を受け付けてくれると良いのだが、まだダメみたい。

サービスに落とし込む

以上を踏まえ、運用可能なサービスに落とし込む。翻訳も運用もコストが最低限・人力が最低限になるように設計する必要がある。サービスの全体像としては、大きく3つのものを作る

1. Checker
   • OSS のドキュメントを取ってくる
   • 以降、翻訳完了したところまでとの差分を取得する
2. Translator
   • Original のドキュメントを翻訳に適切な粒度にバラす
     • コードブロックなどは翻訳しなくて良い。など
   • 足らない情報を追加する（Meta 情報など）
   • パスを修正する（こちらの絶対パスに変換する）
   • AI で翻訳する
   • Validation する
   • 翻訳済みのドキュメントとして再構築する
3. Frontend
   • 翻訳済みドキュメントを読み込んで表示する

Checker

OSS のドキュメントは、ドキュメントも Open Source License で公開されていることが多いので、それを取ってくる。公式に日本語ドキュメントが用意されている場合や、ドキュメントの License が使えなさそうなものは選ばない。

全てのアップデートをフォローするのは厳しいので、定期的にまとめて処理するため、差分を取得する。

Translator

前述の通り、AI 翻訳は指示を無視しがちなので、全て AI に任せるのではなく、AI が翻訳したものを Validation し、必要に応じて再翻訳または修正することにする。どう直すかを翻訳を見て人力で決める必要があるが、どう間違うかはそんなにパターンがないので、割と機械的に修正が可能だ。

例えば、default は英語のままにして指示を出しても、どんなにプロンプトを工夫しても、日本語だと デフォルト、ベトナム語だと mặc định と翻訳してしまう（全てではないのが少し厄介だが）。このような場合は、デフォルト や mặc định を default に一括置換してやるれば良い。そうすることで、指示した通りの結果になることがほとんどだ。Validation にはいくつかポイントがあるが、こんなようなことをエラー率の許容範囲にはいるまで繰り返す。

なお、利用した AI は、Azure で ChatGPT にした。選定理由としては、ベトナムで正式にサービス提供しており、法人契約可能なのがそれしかなかったから。大きなファイルを扱ったり日本語翻訳がなかり優秀な Claude を使う方法はないかと探したが、なかった。残念。

私のやり方だと、フルスタック・フレームワーク（Next.js, Laravel etc）の場合、翻訳するのに、1万〜1.2万回くらい API をコールしている。事前に見積りをした金額に比べ、あれ？ってくらい請求額は低かった。見積もりは単純な Token 数で考えるが、実際に使用されるリソースは、繰り返されるプロンプトはカウントしないとか、そんな感じなのかも知れない。

他にも工夫すべき点はたくさんあるが、細かすぎるので省略。

なにはともあれ、翻訳を外注するコストに対して、ほぼ無料みたいなコストで翻訳できた。

なお、Translator は、試しては作り直しを繰り返したが、設計は私・実装は GitHub Copilot だ。GitHub Copilot に書かせてみたかったので、試してみた。レビューして手直しが必要だが、Translator の実装の8割くらいは、GitHub Copilot でできた。設計能力と、明確な指示出しができれば、エンジニアが実装する必要は、現時点で既にないのかも知れない。

今後 Copilot なしの開発は考えられなくなってくるかも知れないが、明確な指示出しのためにも、ドキュメントの読み込みは重要である。

Frontend

今回は、Next.js を使った。Next.js の App Router でフロントエンドを作ったことがなかったので、ちょうど良い題材となった。翻訳したドキュメントが本当に役に立った笑。

ドキュメントの読み込みは、@next/mdx を利用して、mdx ドキュメントを読み込むようにした。各ドキュメントの独自コンポーネントは作る必要があるが、簡単に取り込むことができる。

作り始め当初、ドキュメントを追加するたびにアプリケーション自体をデプロイするのが嫌だったので、ドキュメントとリポジトリを分け、GitHub API を利用して、revalidate かなぁと作っていたが、とんでもない回数 API をコールする必要があったので諦め、submodule として使うことにした。だったらもう全部静的にしちゃった方が良さそうと、Static + SSG な構成になった。

静的 Build にすると、使えなくなる機能がいくつもあるが、なんとかなったし、圧倒的なレスポンスの速さとのトレードオフにはならなかったので、静的 Build にすることにした。速いって気持ちいい。

サーバは AWS も飽き飽きしていたのと、AWS は（ベトナム）国外サービスであり、経費にできず無駄に税金が発生するので（無税だけど）、Azure の Statice Web Apps を使うことにした。Azure Static Web Apps では、カスタムドメインとして、トップドメインを設定すると、リソース分散されなくなるなどのデメリットはあるが、じゃあどうしたら良いのがいまのところ分からないので、追々というにした。十分速いし。

Azure Static Web Apps へのデプロイは GitHub Actions を利用しており、Pull Request で Staging 環境がスポットで立ち上がったりなど、非常に便利に作られている。サーバ構成の詳細が分からないとセキュリティ的に不安だが、今回は静的だし、ユーザから情報取得しないので（Analytics等以外）、まぁ大丈夫だろうということにした。ただ、Build にものすごく時間がかかるので（いまだと 70 分くらい。手元だと15〜30分くらい）、そのあたり含め、ベストなインフラが何かは検討の余地がある。

また、アクセス解析のため GA4 を埋め込んで Cookie Consent を取るようにしてみたが、3rd Party サービスを使って、個人情報に関連する法律をグローバルで遵守することは不可能に近いので、そのうちやめるかも知れない。Next.js には @next/third-parties という experimental な library があるが、これを使うと、アウトなので、このライブラリは今後に期待したい。

個人情報諸々の詳細は、”訴えられない”ように Google Analytics を使う方法を考える。

あとは、やれる限りのことをやった。

Next.js は本当にフルスタックだった。ポリシー系を除き、page.tsx は 4 つしかない。バンザイ。

ドキュメントを読み込み、あれこれ使ってみると、ここもうちょっとなんとかならないかなぁなどと思うところが生意気にも出てくる。コントリビューターチャンスかも知れない。

スポンサーついたら本気出す

肝心のベトナム語版がまだ公開に至っていないのだが、鋭意作業中である。また、Validation 作業が正直しんどい・面白くない。フルスタック・フレームワークくらいの規模だと、ドキュメント取ってきてから公開できるまで、集中したら1人で1週間くらいかかる。言語ごとにレビュワーを置くのもなぁとも思うので、今後の課題として取り組んで行きたい。明確な判断基準のあるルーチンは、自動化できる。

なお、AI の進化は激しく、ハノイの小さな会社が、Google や ChatGPT などの本気に太刀打ちできるはずもないため、このサービスはいずれ価値がなくなることは目に見えている。消費期限付きではあるが、非英語圏のエンジニアが公式ドキュメントを読むハードルが下がる世界が実現するのであれば、それがこのサービスでなくても良いし、その時はその次の課題に取り組むようなものを作れば良い。

しばらくは遊べれば、それで良いのである。

スポンサーは募集中。メンバーは、法人ニートなのであんまり募集していない。案件は面白そうなのがあれば是非ご一緒したいが、しばらくは法人ニートを満喫したい。