「はじめまして」から4日でマージまで — KubeCon Japan 2026でKubernetes OSS翻訳デビューした話

「はじめまして」から4日でマージまで — KubeCon Japan 2026でKubernetes OSS翻訳デビューした話

KubeCon + CloudNativeCon Japan 2026のKubernetes docs翻訳セッションで、こんなスライドを見た。

"Large AI generated PRs and AI generated commit messages are not allowed."

これは、Kubernetes SIG Docs Japanチームによる「Beyond Translation: The Journey of Building the Japanese Kubernetes SIG Docs Community」(動画)の一節だ。
登壇したのはJunya Okabeさん(Mercari, SIG-Docs Japanese localization approver, CNCF Ambassador)と、Aoi Takahashiさん(Recruit, SIG-Docs member, Kubestronaut)の二人だった。

中身を理解しないままAIに書かせたPRがある。
コミュニティは、それを「AI Slop」と呼んで明確に拒否している。
この記事もAIの手を借りて書いている。
だから最初にこのスライドを置いた。

自分の言葉と一次情報で中身を埋める。
それができなければ、この記事自体がAI Slopになる。
以下はKubernetes docs翻訳に取り組んだ記録だ。

発表を聞いた当日にDMを送った

セッションを聞き終えてすぐ、KubernetesのSlackに参加した。
7月30日19時22分、Okabeさんに直接DMを送った。
翻訳で貢献するのに満たすべき英語力の基準はあるか尋ねたのだ。
別のOSSプロジェクトで、TOEICスコアの下限を見たことがあった。
それで確認したかった。

翌31日1時17分に返信が来た。
要点はこうだ。
英語力についての基準は特に設けていない。
求められるのはむしろ日本語力だという。
目安はJLPT N1/N2程度だという。
ただ、日本語ネイティブなら普通はクリアしている水準だ。
GitHubアカウントを教える。
それだけで、good first issueを用意してくれるという。

基準を聞きに行ったつもりが、「基準はない、やってみればいい」で終わった。
拍子抜けするくらいシンプルな返事だった。

Issueをもらって、Kubernetes docs翻訳のPRを出す

8月1日、Issue #56697がアサインされた。
出したPRは#56710「[ja] Translate content/en/docs/reference/glossary/object.md into Japanese」だ。
中身はKubernetesの用語集にある「オブジェクト(object)」の項目だ。
わずか18行の翻訳だった。

出してすぐ、Linux Foundationのbotから指摘が来た。
CLA(Contributor License Agreement)が未署名だという。
署名がないと、このコミットは受理できないという。
順調にPRを出せた高揚感の直後、地味な事務手続きで足止めを食らう。

CLAで足止めを食らう

ここからが思いのほか長かった。
言われた通りにCLAへ署名しても、チェックは❌のまま変わらない。
Safari・Chromeの両方で試しても結果は同じだった。

SIG Docs Japanのチャンネルで質問してみた。
「EasyCLAがパスしなかったので署名したが状態が変わらない、パイプラインのようなものを流し直す必要があるのか」と聞いたのだ。
Okabeさんが助言をくれた。
PRについていたbotコメントのスレッドを辿ってみるように、とのことだった。
それでも状況は変わらず、最終的には自分でログを追って原因にたどり着いた。

コミットに記録されていたメールアドレスは、EasyCLAに登録したものと違っていた。
それが原因だった。
コミットの著者メールアドレスを直し、pushし直した。
そこでようやくチェックが通った。

これが最初に味わった「OSSは思ったより普通の仕事に近い」という実感だった。
善意やスキルだけでは動かない、ただの設定不備が普通に起きる。

Kubernetes docs翻訳のレビューは間違い探しではなく、言葉の解像度を上げる作業だった

Kubernetes docs翻訳の作業そのものは、自分の英語力と辞書だけで進めた。
翻訳ツールやAIは使っていない。
この記事の執筆にはAIの手を借りている。
だが、PRの翻訳文はすべて自分の頭で考えた言葉だ。

CLAを片付けたあと、レビューが入った。
SIG Docs Japanのメンバー2人からの、具体的な指摘だった。
単純な誤訳の指摘はほとんどなかった。
ほとんどが、日本語としての座りの良さを詰める作業だった。

Aさんのレビュー: 直訳から自然な日本語へ

一人目のレビュアー(以下Aさん)からもコメントが来た。
原文の "your" をそのまま「あなたの」と訳していた箇所だ。
この訳語は適当に置いたわけではない。
ローカライズガイドの基本方針には「意訳に迷ったら直訳」という原則がある。
それに従った結果だった。

Aさんの指摘は、それを一歩進めたものだ。
「特に『あなた』と訳す必要はないように感じました」というコメントだった。
直訳を出発点にしつつ、そこから自然な日本語へどう踏み込むか。
まさに経験がものを言う判断だった。

改行の位置についても指摘があった。
ローカライズガイドの基本方針を示した上で、具体的なルールを教えてくれた。
「日本語文では、文章の途中で改行を行わない。句点『。』もしくは行末のコロン:で改行する」というルールだ。
それとあわせて、修正案ももらった。

Aさんのレビュー: 原語表記とニュアンスの調整

"desired state" の訳にも指摘が入った。
Aさんいわく、「原文を読んでいると頻出する単語の印象で、原文も添えておくと単語として認識しやすいように感じました」。
日本語に置き換えて終わりにはしない。
読み手が後で原語を検索できるように、英語表記を残すという判断だった。

「典型的に」という訳語についても提案があった。
「通常」への言い換えとあわせて、文の組み替え案をもらったのだ。
原文には、コントロールプレーンが調整し続けるというニュアンス(reconciliation)がある。
それをより正確に伝えるための提案だった。

Bさんのレビュー: 用語集としての一貫性

二人目のレビュアー(以下Bさん)は、用語集としての体裁を重視していた。
「にある」を「における」に直す提案があった。
「どちらでもよい程度のことですが、より用語集の説明文らしくしました」とコメントがついた。
意味は変わらなくても、用語集全体のトーンを揃える判断だ。

さらに、私の訳文で原文にはない意味の重複が生じていた箇所も見つけてくれた。
「15行目の後半と16行目が重複していますよね。原文では、2回書かれているようなことはなかったです」という指摘だ。
文の組み替え案と、「項目」ではなく「対象」という訳語の代案まで添えてくれた。

Kubernetes docs翻訳PR、8コミットを経てマージ

このやり取りが8月1日から2日にかけて続いた。
最終的に8コミット分の修正を重ねることになった。
8月3日、kubernetes-prowのbotによってマージされた。
同時に、Issueもクローズされた。
DMを送ってから、ちょうど4日後のことだった。

振り返って

発表のスライドには「レビューも貢献のひとつだ」という一節があった。
実際に受けたレビューは、まさにそれを体現していた。
誤りを直すだけでなく、原文の意図をどう日本語の座りに落とし込むか。
用語集としての一貫性をどう保つか。
レビュアー自身の判断が指摘のひとつひとつに乗っていた。

これは裏を返せば、Kubernetes docs翻訳をAIやツールに任せていたら得られなかった経験でもある。
単語をどう訳すか、その場の判断は自分でもできる。
だが、用語集の文脈や読者の検索行動を踏まえて判断するのは難しい。
ここはあえて直訳を崩した方が自然かどうか、そこまでは一人で見極めきれない。
レビュアーが教えてくれたのは翻訳の正解ではない。
コミュニティがこれまで積み上げてきた判断基準そのものだった。

Kubestronautという生き方

発表そのものの中でも、Aoi Takahashiさんの話が特に印象に残った。
ドキュメントを読んでいて翻訳が必要な箇所を見つけては翻訳する。
翻訳しながら学ぶというサイクルを回し続けた結果、「Kubestronaut」になったという。
これはKubernetesの認定資格をすべて取得した人に贈られる称号だ。

地道な積み重ねが具体的な成果につながっている様子は素直にすごいと思った。
Kubernetesの認定資格をひとつも持っていない自分にとって、これは刺激になった。
まず一つ取ってみようというモチベーションが湧いた。

AI Slopという言葉の重み

「AI Slop」という言葉自体、今回の発表で初めて知った。
自分はふだんの開発でAIを使うこともある。
だが、レビューする側の気持ちで考えたことはあまりなかった。
中身を理解しないまま出された低品質なアウトプットがある。
それをレビューするのがどれだけ負担か、想像が及んでいなかったのだ。
今回、自分が出したKubernetes docs翻訳に対して指摘や提案を一つ一つ受け取った。
そのなかで、自分の変更に自分で説明責任を持つということの重みを実感した。

英語力の心配をしていた自分に言えるのはこうだ。
聞かれていたのは英語力ではない。
日本語の解像度を上げる根気があるかどうかだった。
Slackチャンネル #kubernetes-docs-ja は今日も動いている。
飛び込むための基準は、思っているよりずっと低い。

新規CTA