Appearance
翻訳にもCI/CDを──『Hacking the Xbox』日本語版で試していること（高須正和）
最近、Andrew "bunnie" Huangの『Hacking the Xbox』を日本語に翻訳し、GitHub Pagesで公開する作業をしている。原著と同じCreative Commonsライセンスで、翻訳途中のものも含めてGitHubに置いている。
『Hacking the Xbox』は2003年に出版された、初代Xboxのセキュリティを解析していく過程についての本だ。単なる技術解説ではなく、当時MITの学生だったbunnieが、実際のハードウェアを手に取り、仮説を立て、失敗し、また別の方法を試しながら仕組みに迫っていく過程が書かれている。僕は以前、同じbunnieの『The Hardware Hacker』を、監訳の山形浩生さんに大きくお世話になりながら日本語に翻訳したことがあり、今回も日本語で読めるようにしたいと思っていた。
とはいえ、300ページ近くある技術書を一人で翻訳するのは大変だ。今回はClaude CodeやChatGPTなど複数のAIを使っている。AIがなければ、少なくとも今のタイミングで始めようとは思わなかっただろう。
実際に始めてみると、AIが本を翻訳してくれるという単純な話ではなかった。むしろ、AIが大量の作業をできるようになったからこそ、仕様を作り、成果物をレビューし、問題を仕組みに戻して改善するエンジニアリングが重要になる。今回やっていることも、翻訳というより普通のエンジニアリングに近い。
この方法は、『Hacking the Xbox』で最初に思いついたものではない。もともと、先月2026年の6月にニコ技深圳で翻訳した『2025 China Open Source Report』日本語訳で試したものだ。中国語の報告書を、翻訳ガイドと用語集を更新しながら訳し、気になった表現を次の章へ持ち越す。事実や動向を正確に伝えるレポートでは、このやり方はかなりうまく機能した。
『Hacking the Xbox』で試したかったのは、その方法をCodexではなくClaude Code中心に置き換えても回るのか、そして中国語ではなく英語の本でも同じように使えるのかだった。結果として、仕組み自体は機能した。ただし、同じ「翻訳」でも難しさは違った。
オープンソース年報は、基本的には客観的な報告書だ。一方で『Hacking the Xbox』は技術書でありながら、bunnieが実際に手を動かし、仮説を立て、失敗し、別の方法を試していく物語でもある。用語が正しいだけでは足りない。bunnieが考えている感じや、読者に「自分も試してみたい」と思わせる声を残す必要がある。そのぶん、表現のやり直しは多くなった。むしろ、その試行錯誤が、この本でこの方法を試す面白さになっている。
「AIに作らせればいい」という話が嫌いだ
AIについて、「これからは人間が詳しくなくても、AIに聞けばなんとかなる」「知識を覚えたり、自分で考えたりする必要がなくなる」という話をよく見る。これまで教育や学習にたいして関心があるようには見えなかった人が、AIが出てきた途端に「もう勉強しなくていい」「教科書はAIに作らせればいいじゃん」と言い出すことも多い。
僕はこの考え方が嫌いだし、単に態度として好きではないというだけでなく、間違っていると思っている。
もちろん、AIによって、これまで専門家にしかできなかったことを多くの人が始められるようになるのはよいことだ。英語が得意でなくても海外の情報を読めるし、プログラミングを始めたばかりの人でも動くコードを作れる。文章を書くことに慣れていない人でも、最初のたたき台を作れる。僕自身、この翻訳でAIの能力に頼っている。
でも、作り始められることと、よいものを作れることは違う。少なくとも、新しいものを作る仕事は、その対象が好きでないとなかなかよいものにならない。
ここでいう「好き」は、仕事を楽しくするための気分や、プロフィールに書く趣味のことではない。気になって仕方がない、もっと知りたい、誰もやっていないなら自分で試したい、うまくいかないと悔しい、できたものをほかの人にも見せたい、という欲望に近いものだ。
食欲や性欲とまったく同じだと言いたいわけではないけど、役に立つかどうかも分からないものを調べ、頼まれていないものを作り、効率が悪くても気になるから続ける性質は、生物としての人間に組み込まれているのだと思う。人類がこれまでやっていなかった変わったことを始め、できることの範囲を広げてきたのも、そういう人間の性質によるものだろう。
AIは生物ではないので、この欲望を持っていない。AIに「やりたいこと」があるわけではなく、与えられた目的に対して、限られた計算資源の中でもっともらしい出力を返すように作られている。頼まれてもいないのに、面白そうだから寝る時間を削って余計なものを作ることはないし、役に立つか分からないけど気になるから何年も続けることもない。
人間とAIの大きな違いは、計算能力や記憶容量だけではなく、この「これが面白いからやりたい」があるかどうかだと思う。そして、AIと一緒に仕事をするときに一番重要になるのも、人間の側にあるこの感情ではないかと思う。
何を作るのか、なぜ作るのか、どこが面白いのか、何を失ったら作る意味がなくなるのかは、AIから自動的に出てくるものではない。人間が対象を見て、考えて、決める必要がある。
今回の翻訳は、AIに本を丸ごと渡して、日本語にしてもらったわけではない。AIが作った翻訳を読み、どこが間違っているかだけでなく、どこが面白くなくなっているかを考え、その理由を翻訳の仕様へ戻し、ほかの部分も反映する仕組みを作っている。
AIはすぐ翻訳できるが、そのままでは本にならない
『Hacking the Xbox』の原文をAIに渡せば、数分で日本語が出てくる。文章としてだいたい読めるし、一文だけを見れば、明らかな誤訳ではないものも多い。
でも、章全体を読むとおかしい。技術用語の訳が少しずつ違ったり、英文の構造を引きずった読みづらい日本語になったりする。AIが読者に親切にしようとして、原文にはない説明や見出しを付け加えることもある。
一番大きな問題は、bunnieが自分でXboxを解析しながら考えている感じがなくなることだった。「僕はこう考えた」「こう試した」「これは失敗だった」という個人の体験が、AIを通すと一般的な技術解説のようになる。情報としてはだいたい合っているけど、『Hacking the Xbox』を読む面白さが減っている。
最初は、おかしい文章を見つけるたびに、その箇所をAIに直させていた。一人称の「私」は「僕」にする、この技術用語は別の訳にする、原文にない説明を加えない、英語の一文をそのまま日本語の一文にしない、といった指示をすれば、その場の文章はよくなる。
でも、別の章を翻訳すると、同じ問題がまた起きる。チャットの中では指示を覚えていても、別のセッションや別のモデルには引き継がれない。何十章もある本の細かい翻訳ルールを、毎回プロンプトに全部書くのも現実的ではない。
なので、修正した文章ではなく、修正した理由をリポジトリに残すことにした。翻訳全体のルールはTRANSLATION_GUIDE.mdにまとめ、技術用語や固有名詞の訳はglossary.tsvに入れる。Claude Codeには、作業を始める前にそれらを読み、既存の翻訳との整合性を確認するように指示している。
問題が見つかったときも、その一文だけを直して終わりにはしない。なぜその問題が起きたのか、同じ問題が章内のほかの場所にもないか、ほかの章でも起きる可能性があるかを調べ、個別の修正を今後も使える一般的なルールにする。ルールを翻訳ガイドへ追加したら、新しいルールを使って章全体をもう一度翻訳する。
たとえば第8章で頻出するFPGAを使った信号処理の部分は、僕がその分野の関心が薄いから、面白い（勉強になる、読む気になると言い換えてもいい）かどうかの判断がつかない。 FPGAに造詣の深い @susutawari さんに読んでもらって Issueを立ててもらい、それをもとにChatGPTに章全体から同じ傾向の問題を抽出させた。その結果を個別の修正一覧で終わらせず、今後の章にも使える翻訳ルールに変換し、翻訳ガイドを更新する指示を作った。その新しいガイドを使って、第8章全体をClaude Codeで再翻訳している。
第8章で見つかった問題は、技術的な表現が多い第5章、第6章、第7章、第9章、第10章、第11章にもある可能性が高い。なので、新しいルールはこれから翻訳する章だけでなく、すでに翻訳した章の見直しにも使える。
一か所で感じた違和感を、その一文の修正で終わらせず、過去と未来の翻訳を改善する仕様にする。これが今回の作業で一番面白いところだ。
コミュニティの指摘をルールに戻す
最近の例では、まず@hiyori13からx.comで意見をもらった。はんだ付けの説明に出てくる “solder blob” について、これはBGAのはんだボールの話ではなく、部品を置く前にランドの一つへ「あらかじめはんだを盛る」操作として読むほうが自然ではないか、という指摘だった。つまり、この場面では「はんだブロブ」でも「はんだボール」でもなく、「はんだを盛る」「盛ったはんだ」と訳すのがよい。
同じ箇所について、@tomorrow56さんからは付録Bのはんだ付け表現に対するPRをもらった。PRでは “solder blob” に「予備ハンダ」という訳語が提案され、その修正はmainへ取り込んだ。
この二つの指摘を、一文だけの修正で終わらせなかった。文脈によって「予備はんだ」と呼ぶのが自然な場合もあれば、「はんだを盛る」と動作で訳したほうが自然な場合もある。そこで、訳し分けを翻訳ルールに戻すことにした。まず翻訳ガイドと用語集に訳し分けを追加し、そのうえで付録Bを新しいルールで再翻訳した。
さらに、追加したルールがどこに影響するかも確認した。はんだ付けそのものを扱う付録Bは再翻訳し、信号やバスの表現が多い第8章や、PCBレイアウトを扱う付録C、LED取り付けやUSBアダプタの章も重点的に見直した。関連する修正は、たとえば第3章・第4章・付録Cの用語と単位表記の修正として残っている。
指摘は、誤字修正や表現の好みの話で終わらないことがある。その指摘を読むことで、翻訳ルールそのものが少し賢くなる。次にAIが訳す文章も、すでに訳した章の見直し方も、そのルールによって変わる。
翻訳にもCI/CDを持ち込む
CI/CDは、もともとはソフトウェア開発で使われる言葉だ。CIはContinuous Integration、継続的インテグレーションの略で、開発中の変更を小さい単位で頻繁に共通のリポジトリへ統合し、そのたびにビルドやテストを行って、問題を早く見つける考え方だ。CDはContinuous DeliveryまたはContinuous Deploymentの略で、テストを通った成果物を、いつでも公開できる状態にしたり、実際に継続して公開したりする仕組みを指す。
大きな変更を最後にまとめて確認するのではなく、小さな変更を加えるたびに検証し、問題があればすぐ戻して直す。変更、テスト、公開、フィードバックの周期を短くすることで、成果物を少しずつ改善していく。
今回の翻訳はソフトウェアではないし、日本語として面白いかどうかを自動テストだけで判断できるわけでもないので、厳密な意味でCI/CDを実装しているわけではない。でも、翻訳結果を一度作って完成とせず、人間が読んで問題を見つけ、その問題を仕様へ戻し、新しい仕様で成果物を再生成して公開する流れはかなり似ている。
具体的には、次のような作業を繰り返している。
- AIが作った翻訳を、人間が章全体を読みながら手で直す。
- 修正前と修正後をChatGPTに渡し、同じ種類の問題を抽出する。
- 個別の修正を一般化し、翻訳ガイドや用語集へ追加する。
- 人間が生成されたルールを確認し、必要なら修正する。
- Claude Codeが更新されたルールを組み込み、章全体を再翻訳してサイトをビルドする。
- GitHub Pagesで公開し、読者からの指摘も次の修正とルール作成に使う。
ChatGPTには主にレビューと問題の一般化をさせ、Claude Codeにはリポジトリにあるファイルを読み、実際の翻訳、修正、ビルドをさせている。GitHubには翻訳結果だけでなく、翻訳ルールと、そのルールを変更した履歴も残る。
文章を一つずつ直すのではなく、次に作る文章がよくなる仕組みを直している。入力があり、仕様があり、実装があり、レビューがあり、問題が見つかれば仕様へ戻るので、やっていることはエンジニアリングそのものだと思う。これは、本の内容を変えているという話ではない。たとえば今回の訳ではセガや任天堂などの日本メーカーや製品はカタカナや日本語、Microsoftは英語表記のままにしているが、それはもともと全部英語でこの文章を書いたbunnieの頭の中にはないことだ。翻訳者が、読んだ人がどう思うかを視点に考えなければならないことだと思う。
AI時代には仕様とレビューがもっと重要になる
AIは、とにかくたくさんのものを短時間で作れる。文章もコードも画像も、これまでとは比較にならない速度で生成できる。なので、仕様が曖昧なままだと、曖昧な成果物が大量に出てくる。
一文だけなら、人間がその場で直せばよい。でも、本一冊、大きなソフトウェア、何年も続くプロジェクトになれば、個別の修正だけではどうにもならない。何を正しいとするのか、どこまで原文に忠実にするのか、どの言葉を統一するのか、AIが説明を加えてよい範囲はどこまでか、何を変えてはいけないのかを、仕様として決める必要がある。
しかも、最初から完全な仕様を作ることはできない。今回も、まずAIが作った翻訳を人間が読んで手で直し、その具体的な修正からChatGPTにルールを抽出させた。実際の成果物を見なければ、何をルールにするべきか分からなかったからだ。その後も新しい章を読むたびに想定していなかった問題が出てくるので、成果物を作り、レビューし、その結果をもとに仕様を更新するしかない。
AIが実装の多くを引き受けるようになるほど、仕様を考えることと、仕様そのものをレビューすることは、これまでより重要になる。「AIがあるから詳しくなくてもよい」のではなく、詳しくなければ、出てきたもののどこがおかしいのか分からない。仕様が間違っていることにも気づけないし、AIがもっともらしい間違いをしたときにも止められない。
ただし、仕様をきちんと作れば全部解決するわけでもない。誤字がない、用語が統一されている、原文の情報が抜けていない、余計な説明を追加していない、といった条件は仕様にできる。でも、完成した文章を読んで面白いかどうかは別だ。
正しいけどつまらない文章はある。読みやすいけど、原著者の声がしない文章もある。仕様を全部守っていても、その本を翻訳する意味がなくなっていることもある。
AIに「面白い文章にしてください」と指示することはできる。でも、出てきた文章が本当に面白いのか、この本の面白さを残しているのかは、最終的には人間が判断するしかない。成果物に意味があるのか、世の中に出す価値があるのか、そもそもなぜこれを作るのかも、人間が決めることだ。
そして、その人間は誰でもよいわけではない。
翻訳なら、その本が好きな人が必要だ。ソフトウェアなら、そのソフトウェアが解決しようとしている問題を気にしている人、製品なら、その製品を使う人や、それによって起きる変化に興味がある人が必要になる。対象に興味がない人でも、仕様に合っているかは確認できるかもしれない。でも、面白いか、つまらないか、大事なものを失っていないかを判断するのは難しい。 FPGAの話で @susutawari さんにメンション飛ばして読んでもらったのも、彼がFPGAに詳しいことはもちろんだが、それだけではなくて、「この文章を面白がって読んでくれそうだな」という期待があった。面白がって読んでくれないとダメなのだ。
僕が『Hacking the Xbox』の翻訳をレビューできるのも、英語と日本語が分かるからだけではない。僕自身がハードウェアハッキングやオープンハードウェアに長く関わり、この本を面白いと思っている。著者のbunnieを知っていて、『The Hardware Hacker』も日本語に翻訳した。この本がどういう人によって書かれ、どこが面白いのかについて、自分なりの理解がある。
だから、情報としては正しく見えても、「これはbunnieの文章に見えない」と判断できる。もちろん、その判断が必ず正しいわけではないので、GitHubで公開し、ほかの読者からのIssueも受け付ける。それでも、最終的に成果物に意味があるかを判断し、公開する責任を持つ人は必要だ。それはチェックリストを消化する人ではなく、その成果物が好きで、「ここが面白い」「これは残さないといけない」「こうなったら意味がない」と言える人だと思う。
AIは人間の代わりに好きになってくれない
AIによって、文章を入力したり、コードを一行ずつ書いたりする作業は減っていくだろう。でも、人間が知らなくてよくなるわけでも、考えなくてよくなるわけでもない。
人間が考えることは、何を作るのか、なぜ作るのか、何を正しいとするのか、どういう仕様にするのか、出てきたものは面白いのか、それを世の中に出す意味があるのか、ということへ移っていく。AIが大量に作れるようになるほど、その判断をする仕事は増える。
AI時代だからエンジニアリングが不要になるのではない。AI時代だからこそ、仕様を作り、成果物をレビューし、問題を一般化し、仕組みに戻して改善するエンジニアリングが必要になる。
そして、その工程の始まりにも終わりにも、「これが面白いからやりたい」と思う人間が必要になる。AIは多くの作業を手伝ってくれるけど、人間の代わりにその成果物を好きになってはくれない。
『Hacking the Xbox』日本語版は、まだ翻訳途中だ。一度翻訳した章も、翻訳ガイドが更新されれば、また見直して再翻訳する。読んでいて誤訳や技術的におかしい部分、日本語として違和感がある部分を見つけたら、GitHub Issueで教えてほしい。その指摘は一つの文章を修正するだけでなく、翻訳ルールに加わり、これから翻訳する章や、すでに翻訳した章も改善するかもしれない。
翻訳だけでなく、翻訳する仕組みそのものを継続的に改善していく。それが今回、『Hacking the Xbox』日本語版で試していることだ。