Zennの自動翻訳機能から学ぶプロダクト開発の難しさ
はじめに
2026年1月、Zennに自動翻訳機能が導入されました。著者が翻訳を許可した記事について、記事URLに?locale=enをつけることで英語版が読めるようになったのです。
当初はデフォルトでONになっていたこの機能、賛否両論を呼び、運営は速やかにデフォルトOFFへと変更しました。この一連の流れを見て、私は「プロダクト開発って本当に難しいな」と改めて感じました。
今回は、Zennの自動翻訳機能を題材に、プロダクト開発における様々な視点や課題について考えてみたいと思います。
まあいわゆるそういう訓練というか備忘録も兼ねてるよんって話です。
何が起きたのか
まず、時系列関係を整理しましょうか。
2026年1月9日（金）、午後16時ごろ、Zenn公式から機能リリースの発表がありました。
記事に?locale=enパラメータをつけると英語版が表示される、AI による自動翻訳機能リリースです。この時点では、デフォルトでONになっていました。
つ、ツイート内容にできれば「もうやってるよ」なのか「いつからやるよ」なのか書いてほしかった、というわがままはあります。
開始します！なので、数日後にやるよ～のPR的なやつか？と私は解釈したんですよねえ、この時。
まあ、リンク飛べばわかるので良いか、と。
ふむふむタイム。
私「デフォルトon？！」
忘れないうちにOff,ﾖｼ！ ( ΦωΦ)σ
そして、同日深夜（日付が変わるころ）、運営から再度アナウンスが。
デフォルトをOFFに変更したとのこと。
リリースから設定変更まで、わずか数時間。
思っていたより批判の声も多かったのだと思います。
華金の夜に速やかに対応してくれたエンジニアの皆さん、本当にお疲れ様でした。ありがとうございます。
ゆっくり三連休過ごせてるとええな。
機能の概要：
- 著者が設定で翻訳を許可した記事について、
?locale=enパラメータをつけると英語版が表示される - 翻訳を許可していない記事では、パラメータをURLに付与しても404エラーが返される
- AIによる自動翻訳
- デフォルトON → 即日OFF に変更
つまり、著者が選択できる仕組みではありましたが、デフォルトがONだったことで「知らないうちに翻訳されていた」という状況が生まれたわけです。
実際の挙動：
私が実際に確認した時は、以下のような状態でした。
-
翻訳済みの記事：
?locale=enで英語版が表示される -
翻訳未処理の記事：
?locale=enをつけても404エラー- 翻訳を許可していない場合
- 許可しているが、まだ順次生成が回ってきていない場合
- 公式によれば「順番に生成していく」とのこと
- Zenn Tech Blogを除き、一般ユーザーの記事は翻訳処理が順次進行予定
- マークダウンで書かれたテキスト部分：翻訳される ✅
- コードブロック内のコメント：翻訳される
- 画像内のテキスト：翻訳されない ❌
- URLの
hl=ja-jpなどのlocaleパラメータ：変換されない ❌
つまり、人によっては自分の記事で英語版を確認できる人もいれば、まだ見れない人もいる状況です。しかも404エラーだけでは「許可してないから404なのか、処理待ちで404なのか」が分からない。これも混乱の一因かもしれませんね。
一部の記事より少しずつ実施していく予定です。そのため、設定を有効にされている場合でも、すぐにすべての記事が翻訳対象にはならない点についてご了承ください。
と書いてはあるんだけどね。
例えば、Zenn公式のこの記事を見ると、本文は英語になっていますが、画像内の説明は日本語のままです。また、Google Cloudのドキュメントへのリンクも?hl=ja-jpがそのまま残っています。
まあ、実験段階ってのもあるけど割と「中途半端感」はちょっと感じますね。
技術的な課題：なぜ翻訳は難しいのか
画像内テキストの問題
技術記事では、時に図解やスクリーンショットが重要な役割を果たします。
チャットのスクショとか良い例ですね。
内容が伝えたい内容、概念として理解してほしいとかあります。
しかしまあ、画像内のテキストを自動翻訳するのは技術的にかなりハードルが高いよねって。
この領域は絶賛やっとる！って人も多いかもですが。(最近OCR技術も盛り上がってて見かける度ワクワクする)
完全自動化しようとすると
- OCRで画像内テキストを抽出
- テキストを翻訳
- 同じレイアウト・デザインで画像を再生成
- フォント、サイズ、位置を調整
これ、コストも時間もかかります。しかも品質を保証するのが難しい。
とはいえ、最近めちゃ早くなってるのも事実。
これも出力英語で、かつ、認識できるものっていう条件がつくんだけども。
あとまあ「再生成」の区分になっちゃうから、また色々権利周りがややこしいことになる(日本と世界での法律とかと色々ありすぎる)
読み手の認知負荷
言語の切り替えって、思った以上に人間側に負担がかかります。
記事本文は英語で読んでいるのに、急に画像が日本語だと、「えっと、これは何て書いてあるんだ？」と一瞬止まってしまう。技術記事って、困っているときに読むことが多いじゃないですか。あと知見探しの時。そんなときに余計なストレスがかかるのは避けたいですよね。
というか私は避けたい。
脳みその切り替えミスって一回バカになる時間が発生するっていう私特有のアホかもしれんですけど。
これが日常的にバイリンガル環境(職場やご家庭などなど)にいる人なら慣れているかもしれません。でも、そうでない人にとっては結構な負荷になります。
言語学的な距離
英語とドイツ語みたいに、同じゲルマン語派の言語だと、知らない単語でもなんとなく推測できることがあります。
例えば：
- 英語：go → ドイツ語：gehen（ゲーエン）
- 英語：have → ドイツ語：haben（ハーベン）
でも、日本語と英語は言語的にかなり遠い。
しかも、日本語と英語では言語の視点そのものが根本的に異なると言われています。
言語学者の金谷武洋氏（元モントリオール大学東アジア研究所日本語科科長、専門：言語類型論）は、日本語を「虫の視点」、英語を「神の視点」と表現しています。
参考文献：
- 金谷武洋『日本語と西欧語 主語の由来を探る』講談社学術文庫、2019年
- ISBN: 978-4065160695
- 講談社BOOK倶楽部
- 金谷武洋『英語にも主語はなかった 日本語文法から言語千年史へ』講談社選書メチエ、2004年（原著）
- ISBN: 978-4062582889
虫の視点（日本語）：
- 地上にとどまり、状況の中に入り込む没入型の視点
- 話者自身の主観的な視点で世界を捉える
- 例：「国境の長いトンネルを抜けると雪国であった」
→ まるで自分がその場にいるかのような没入感
神の視点（英語）：
- 上空から俯瞰して状況全体を見下ろす俯瞰型の視点
- 客観的で不動の視点から世界を描写する
- 例：「The train came out of the long tunnel into the snow country」
→ 上空から電車の動きを見ているような客観的描写
この根本的な視点の違いが、単純な単語置き換えでは済まない翻訳の難しさを生んでいます。
ゲームで言うFPS(（First Person Shooter）は一人称視点)とかTPS(Third Person Shooter）は三人称視点（キャラクターの後ろや斜め上から）で、周囲を見渡しやすいのが特徴)という認識の違い、と言った方が伝わりやすいですかね？
技術記事でも、「〜してみた」「〜していく」といった日本語特有の表現は、この「虫の視点」に根ざしているため、英語への翻訳が難しいんですよね。
そして私が自分で英記事執筆をしている時に定期的に「んなーーーー」って頭を抱える理由もこれですね。母国語が日本語のはずなのに、もう5周くらいまわって、全然わからなくなるのもこれです。
なんだこの島国言語、なんなんだ本当に……MIYABIな言語ですね……本当に……。
URLのローカライゼーション問題
記事内のリンクが日本語版のURLのままなのも、細かいけど地味にストレスです。
https://cloud.google.com/appengine/docs/flexible/ruby/runtime?hl=ja-jp
^^^^^^^^
これが残ったまま
もちろん、多くの場合リダイレクトは働くし、ブラウザの翻訳機能もあります。でも、「せっかく英語版を見てるのに」という微妙なモヤモヤは残ります。
体験に微妙にストレスがある状態がある。
いや人によるか。個体差。
Zennだからこその議論
ここで一つ、興味深いなって思った点があります。
「これだけ賛否両論が出たのは、Zennがエンジニアのコミュニティだからこそ」という点です。
エンジニア適性を持つユーザー層
Zennのユーザーは、技術的な詳細に気づく人たちです。
いつも私の記事に遊びに来てくれる人たちや、記事を書いている人たち、ROM専ありがとね。
- 画像内テキストが翻訳されない仕組みの理由
- URLの
localeパラメータが変換されない問題 - コードブロック内のコメント翻訳の是非
こういった具体的な指摘ができるのは、エンジニアならではよねって。
速攻でオプトアウトオプトインに言及してたのも良いね～ってほっこりしたくらい。
ここがこうだ、ここがあれだ、と賛否はあれど盛り上がっていて、良いコミュニティだよな、と。
具体で出てくるのは良いよな、って。
通常のプラットフォームならどうだったか
もしこれが、一般的な投稿型コミュニティだったら？
おそらく、賛成意見で埋もれていたルートもあるよな、って思います。
人間は基本的に怠惰ですし、そもそもオプトアウト？オプトイン？って層もいますしね。
「勝手に翻訳してくれるならラッキー」
「別にOFFにするほど困ってないし」
「そもそも翻訳の仕組みとかよく分からないし」
デフォルトONのまま、多くの人は何も言わず受け入れる。翻訳周りの技術的課題やニュアンスの問題に具体的に言及する声は、ごく少数になりかねません。
でも全然該当ツイートの引用とか見てると、ここ気になるから移動するわ、とか。
ここ良いけど、ここ気になる、とか建設的なものが多かった印象です。
まあちゃんと怒ってくれる人たちがいるって健全だよなって思います。
とはいえ、これがプロダクト改善を難しくする
ユーザーからのフィードバックがないと、運営は「問題ない」と判断してしまいます。
というか、判断材料がないと改善とか出来ねぇんですしね。
独りよがりになっちゃうし、サービスとして破綻して結局閉じることにつながっちゃうしね。
【悪循環パターン】
デフォルトON
↓
ユーザー「まあいいか」（声を上げない）
↓
運営「問題ないようだ」
↓
改善されないまま定着
↓
後から問題が顕在化
でも、Zennの場合は違いました。
【良循環パターン】
デフォルトON
↓
ユーザー「ここがおかしい」（具体的指摘）
↓
運営「ご、ごめん…。マイナスの反響もあることは織り込み済みだけど、想定以上に批判課題があるな」
↓
速やかにデフォルトOFF
↓
改善の余地を残せた
まあ、ユーザーの意見を信じすぎても良くないですし
ユーザーの言いなりになるのも良くないというバランス感覚が大事とかいう話もありますが。
ユーザーの声を信じすぎるのも問題
ただし、実験やデータ収集において重要なのは、ユーザーの声だけを頼りにしないことです。
マクドナルドの有名な失敗例があります。
マクドナルドのサラダマックの事例：
- アンケートで必ずと言っていいほど「ヘルシーなメニューがほしい」という要望が出る
- その声を受けて「サラダマック」を導入
- めちゃくちゃ要望されていたのに、全く売れなかった
- 一方、その後に販売されたクォーターパウンダーやビッグマックは大ヒット
- これらはヘルシーとは正反対なのに、ブームを巻き起こした
なぜこうなったのか？
人はアンケートでさえ「噓」をつくからです。もちろん意図的な嘘ではありません。
「ヘルシーなものを食べたい」というのは、思考の中で捏造されたもの。
- 「こう考えるのが正しい」
- 「こう答えておけば大丈夫」
こういった優等生的な回答をしてしまう。でも本心では、体に悪そうなジャンクなものを求めているんです。
というかヘルシーそんな言うなら、サラダバーとかにでも行けばいいですし。
マクドナルド行くって時点で、ジャンクなもの食べたい！なのにね、大抵。
声より行動、アンケートよりデータ
だからこそ、重要なのは
- ユーザーが「言うこと」ではなく「やること」を見る
- アンケートの回答ではなく、実際の行動データを分析する
- 年齢、性別、利用頻度、実際の選択といった客観的データ
Zennの場合も同じです。
「翻訳機能いらない」という声があったとしても、実際のデータで
- 英語版経由の流入が増えている
- 海外からのエンゲージメントが上がっている
- オフにする人は実は少数
となれば、それが真実です。
とはいえ、AEO周りはまだ模索っぽいですが。
逆に、
「翻訳機能ほしい」という声があっても、実際には
- 誰も英語版を見ていない
- AIにも参照されない
- すぐにオフにされる
なら、それも真実です。
バランス感覚が大事
だからといって、ユーザーの声を無視していいわけではありません。
カスのサービスで人が離れるので、コミュニティ系はそもそも人がいないと盛り上がらなくてサービス終了になっちゃいますからね。
理想的なのは：
ユーザーの声（定性データ）
+
実際の行動（定量データ）
=
より正確な判断
- 声で「問題点」に気づく
- データで「本当にそうか」を検証する
- 両方を見てバランスよく判断する
Zennの今回の対応も、まさにこれです。
- 声：「デフォルトONはおかしい」という指摘
- 即座に対応してデフォルトOFF
- これからデータを見て、最適な形を模索していく
エンジニアコミュニティの価値
技術的に詳しいユーザーが多いことは、プロダクト開発にとって実はすごく価値があるな～って思いました。
私が好きなのもそういう理由なのですが。
- 具体的な問題点の指摘
- 技術的に実現可能な代替案の提案
- 建設的なフィードバック
「文句ばっかり言う面倒なユーザー」ではなく、「一緒にプロダクトを良くしてくれるパートナー」として見ることもできます。
もちろん、運営側にとっては大変です。
あんまぺちぺち殴られると運営も人の子なので萎えますしね。
でも、この「厳しい目」があるからこそ、Zennは技術者に信頼されるプラットフォームでいられるのかもな、と思いました。
とはいえ、今回の一件で離脱や異動も散見されましたけどね。
様々な立場からの視点
この機能について、ユーザーの反応は様々でした。それぞれの立場から考えてみましょう。
肯定的な視点：「いいじゃん！」派
「英語版が自動で作られるなんて便利！」
「海外の人にも読んでもらえるチャンスが増える」
「自分で翻訳する手間が省ける」
こういう意見、めちゃくちゃ分かります。特に技術記事メインで書いている人、専門用語が多くて文体にそこまでこだわりがない人にとっては、純粋にメリットですよね。
懸念派：「ちょっと待って」派
一方で、こんな声もありました。
「翻訳の質をコントロールできないのは困る」
「自分の名前で出る以上、責任を持ちたい」
「ポエム系の記事、ニュアンス伝わらないだろうな」
これも分かります。特にアイデア系、マネジメント系、ポエム寄りの記事を書く人にとって、文体やニュアンスは本質的な部分です。
日本語特有の表現って、翻訳が難しいんですよね。
冒頭で私も意図して顔文字使ったけど、これどうやって翻訳するつもりなんだろ、って興味本位もあるけどオフにしてます。
例えば：
- 「ぬるっとした挙動ですね」(動画系や3Ｄ系など)
- 「ワイワイやってます」(オノマトペ)
これ、英語でどう訳すんだって話です。
オノマトペ系ですね。
ですます、口語勢とかは軒並み翻訳がエキサイトの気配がします。
というか、個人的に不安ポイントですね。(私がですます+口語なのもありますが)
まあ、キッチリカッチリしたゴリゴリのつよつよ硬派なTech記事とかだと減るんですけど、Idea系だと増えるんじゃないかなあ、わからんけど。
撤退派：「信頼が損なわれた」派
実際に、この件でZennを離れた人もいたようです。
「事前説明なしにデフォルトONはないでしょ」
「自分のコンテンツなのに勝手に変えられた」
プラットフォームへの信頼の問題として捉える人もいました。
なぜこれほど議論になったのか
著者性とコントロールの問題
記事の文体（ですます調、である調、口語など）は、著者のidentityの一部です。「自分が書いたもの」として世に出る以上、コントロールしたい。
翻訳は、ある意味「別の人が書いたような感じ」になってしまう可能性があります。特にポエム系やエッセイ系の記事では、文体が本質そのものだったりします。
「読まれたい」と「どう読まれたいか」は別
「個人ブログでいいのでは？」という意見もありました。確かに、Zennを使う理由の一つは個人ブログと比較した時の「読まれやすさ」です。
AI引用元でもqiitaよりは低いですがZennもベスト20くらいには入ります。
でも、「読まれたい」と「どう読まれたいか」は別の話なんですよね。
- たくさん読まれたい：Zennのメリット
- 正確に、意図通りに読まれたい：著者のコントロール欲求
この二つは、必ずしも矛盾しないけど、場合によっては対立します。
この当たりは技術記事とかどういうスタンスで書いてる～？って私の過去Zenn記事でも話してますし、Zenn記事内でも色々言及している方がいるので見てみても良いと思います。
オプトイン vs オプトアウト論
「嫌ならオフにすればいいじゃん」
これ、一理あります。実際、私もオフにしました。設定から簡単に変更できます。
でも、問題はデフォルトがONだったことです。
デフォルトONの影響：
- 設定を確認しない限り、知らないうちに翻訳されている
- 「自分のコンテンツが勝手に変更された」感覚
- 気づかずにONのまま放置する人も出る
- 404検証で気づいた人もいれば、気づいてない人もいる可能性
デフォルトOFFの方が良かった理由：
- ユーザーの能動的な選択を尊重
- 新機能として告知→試したい人が使う
- 段階的な普及が可能
- 「知らないうちに」がない
ただし、企業としては「多くの人に試してもらいたい」という意図もあったでしょう。データを取るには、デフォルトONの方が効率的です。そして、実際に速やかにデフォルトOFFに変更したことで、ユーザーに選択権を戻しました。
結構AI系のサービスでデフォルトONでってのも多いです。
特に海外サービスは。
ここら辺割と賛否両論はいまだにあるよね。
そもそも設定できるとこないやんけ？！とかもザラにある。
もうそれだけで個人的に萎える。
使い方でコントロールは出来るんだけどもさ、っていう。
あとZennは記事途中での有料っていう機能はないけど、有料記事をAIが勝手に補足してとかで
結構記事系でのAIで生成、再生成ってつい最近燃えたんだよねっていう。
プラットフォーム依存のリスク
Zennを使うということは、「場を借りている」関係です。利用規約上も、プラットフォームの方針に左右されるリスクは受け入れているはず。
でも、「受け入れられる範囲」は人によって違います。
トレードオフの構造：
【Zennの利点】
- リーチの広さ
- コミュニティ
- 収益化の仕組み
【引き換えに受け入れること】
- プラットフォームの方針変更
- 機能追加や仕様変更
- ある程度のコントロール喪失
このバランスをどう取るかは、人それぞれです。
私もまあ正直ちょっと迷っちゃったよね。
無料で使わせてもらってるわけだけど、オフれる機能もあるし、情報のアプデをキャッチ出来たから良かったけど、っていう。
特に今は企業のテックブログの投稿場所としても選んでもらってたりするのにねっていう。
ちょっとリリースのやり方、冒険しちゃったね、って思います。
年一投稿勢とか会社のアドベントカレンダーの時だけって層も確実にいるしね。
「公開」という行為の法的な意味
ここで、法律的な観点も見ておきましょう。
「公開した時点で、どう利用されても仕方ない」という意見も見かけました。
でも、これは法的には正確ではありません。
著作権法において、公衆送信権と翻訳権・翻案権は別個の権利として扱われています。
つまり
- 「公開すること」への同意 ≠ 「翻訳されること」への同意
Zennの利用規約を見ても、利用者が許諾しているのは「掲載と配信」であって、翻訳・翻案については明示的な許諾は含まれていません。
この点について、@philomagiさんが非常に詳しくまとめられています。
本当は私も書くかって思ってたんですけど、既にしっかりまとまって検討されてたのと「せやね～」となったので甘えていきます。
著作権法、利用規約、Creative Commonsライセンスの3層から「公開」の同意範囲を検討されており、法律面での理解も深めたい！そっち方面も気になってるんだよね、って方にはぜひ読んでいただきたい記事です。
参考記事：
Zennの自動翻訳から考える『公開』の概念
もちろん、Zennとしては「設定でON/OFFできる」という形で、利用者の選択権を提供しています。
デフォルトOFFに変更したことで、この法的な問題もクリアになりました。
というか普通にまあ、この当たりちゃんとしてなかったの内部大丈夫そ？みたいな別の不安も出はしましたけど、私はZennの運用チームでもなんでもないので、ちょっとさすがにそこまで気に掛けるのは違うので詳細は言及しませんが、結構危ない橋を渡ってたよってのは内部側でも学びがあると良いんじゃねぇかな、とはおせっかいで思います。
ただし、この議論は「プラットフォームはどこまでできるのか」という重要な問いを投げかけています。
実験主義の正当性：やってみなきゃわからない
ここで視点を変えてみましょう。
「試してみて、実際のデータを見なきゃわからないでしょ」
これ、めちゃくちゃ正しいと思います。というか、まあそりゃそうって話ですしね。
データなき判断は机上の空論
事前に予測できたこと：
- 翻訳機能を喜ぶ人もいるだろう
- 嫌がる人もいるだろう
でも、どれくらいの割合かは、やってみないと分かりません。
- オフ率はどれくらいか
- 英語版経由の流入は増えるか
- ユーザーエンゲージメントはどう変化するか
- 誤訳によるトラブルは発生するか
こういったデータは、実際に機能をリリースしないと取れないですしね。
仮説と真実は違うよねとかはいつものことです。
企業運営の現実
Zennは、個人開発のcatnoseさんからクラスメソッド（企業）へと運営が移りました。
企業運営である以上
- 利益追求が必要
- 成長戦略が必要
- 実験とデータ収集が必要
これは当然のことです。ボランティアじゃないんだから。趣味の開発じゃないんだから。
▽譲渡に関してのお話(こちらも学びの多いお話)
今現在(2026年1月)すでに個人の手を離れて数年たっているので、個人のものというより完全に企業のもの、として運用されている認識です。
「代替案なき批判」の問題
「会議でいちゃもんだけつけて代替案出さずに邪魔してそう」
これは辛辣ですが、的を射ている部分もあります。
批判のパターン：
- 建設的批判：問題点＋代替案＋実装方法の提案
- 非建設的批判：問題点だけ指摘して終わり
- 感情的拒否：「とにかく嫌」
プロダクト開発において、建設的な批判は貴重です。でも、ただ否定するだけでは何も前に進みません。
あと萎えるよね！ほんとね！！
AI自動化の本質的なジレンマ
この問題、実は「AI時代の翻訳の在り方」という、もっと大きなテーマにつながっています。
効率化 vs コントロール
AI自動化の最大の魅力は「楽になる」ことです。でも、楽になる代わりに、コントロールを失います。
完全手動翻訳：
- 著者が全てコントロール ✅
- めちゃくちゃ時間かかる ❌
完全自動翻訳：
- 時間かからない ✅
- コントロール失う ❌
理想（セミオート）：
- AI が下書き作成
- 著者が確認・修正
- でも手間はかかる
「任せられる範囲」の個人差
何をAIに任せられるかは、人によって全然違います。
技術記事の専門用語
- 翻訳任せてOK派：「専門用語は大体同じだし」
- 慎重派：「微妙なニュアンス違いが命取り」
表現やニュアンス
- 任せられる派：ほぼいない
- 任せたくない派：ほとんど
この境界線が人によって違うから、「デフォルトでどうするか」が難しいんですよね。
完璧な自動化は幻想
翻訳って、単なる単語の置き換えじゃありません。文化、文脈、意図、ニュアンス、全部含まれています。
だから、完全に自動化して人間のチェックなし、というのは現状では厳しい。
でも、人間のチェックを入れると「自動化」の意味が薄れる。
このジレンマ、翻訳に限らず、AI時代のコンテンツ制作全般に言えることです。
建設的な提案：こうしたらもっと良くなる
批判だけじゃなく、「こうしてほしい」を考えてみましょう。
というか、こういうの考えるの楽しいんだよな。
こういうの欲しいよね～とかああなると良いよね～、実装されるかはわからんけどね～っていう。
夢を見るのは楽しいもんさ。
記事単位での翻訳設定
現状は、アカウント全体でON/OFFを切り替える仕組みです。でも、記事によって翻訳の必要性は違いますよね。
記事の性質で使い分けたいケース：
技術記事（コード多め）
→ 英語版ほしい（専門用語は翻訳しやすい）
アイデア記事（ポエム系）
→ 日本語オンリー（ニュアンスが大事）
チュートリアル系
→ 英語版ほしい（グローバルに役立つ）
日記・雑記
→ 日本語オンリー（身内向け）
提案する仕組み：
-
記事編集画面に翻訳設定を追加
[ ] この記事の翻訳を有効にする -
記事タイプ別のデフォルト設定
設定画面で： ■ tech記事：翻訳ON ■ idea記事：翻訳OFF -
より細かい言語選択
翻訳対象言語： [✓] 英語 [ ] 中国語（簡体字） [ ] 韓国語
こうすれば、著者が記事ごとに最適な判断ができます。
多言語はあるかもか？
理想的な機能仕様
現状だと、翻訳結果を編集できません。これが一番の問題だと思います。
理想のワークフロー：
1. 日本語版を執筆
2. 「英語版を生成」ボタンをクリック
3. AI翻訳が「下書き」として生成される
4. 著者が確認・修正できる
5. OKなら公開、ダメなら修正続行
これなら：
- AI翻訳の効率性を活かせる
- 著者がコントロールを持てる
- 品質を担保できる
とはいえ、この「自力」で英編集できる勢は、そもそものZennで本当に必要？はあるかも。
普通にローカルとか別で自分でやるし、という。
まずそも、自力の英語の違和感、翻訳の違和感を検知できるかという別の力が問われちゃうんだよなあ。
言語切り替えエディタ
記事編集画面で、日本語版と英語版を切り替えられると便利です。
エディタ上部に：
[日本語 🇯🇵] [English 🇬🇧]
クリックで編集対象言語を切り替え
こうすれば、英語版だけ特別な説明を追加したり、文化的背景の補足を入れたりできます。
これ割と普通にほしい。当たり前って全然違うからね。
画像の言語別アップロード対応
画像も、言語ごとに別々のファイルをアップロードできたら理想的です。
image1_ja.png → 日本語版で表示
image1_en.png → 英語版で表示
技術的には、ファイル管理が複雑になるので実装コストは高いですが、ユーザー体験は大幅に改善されます。
「AI翻訳です」表示
シンプルだけど効果的なのが、記事上部に翻訳であることを明示することです。
ℹ️ This article was automatically translated
from Japanese using AI.
[View original (日本語)] [Report translation issue]
これだけで：
- 読者の期待値が調整される
- 著者の責任範囲が明確になる
- 誤訳への理解が得られる
まあ、こういうの気にするの日本人特有なんだけどね。
そもそもの頭の部分読んで、変だな、とか何かキモいなって思ったら早々に大多数のユーザーは離脱するだけ、という現実なんですけどね。
404エラーの改善
現状、404エラーが返されるだけでは、その理由が分かりません。
【現状】
404 Not Found
【改善案】
■ 翻訳未許可の場合
"This article's translation is not enabled by the author."
■ 処理待ちの場合
"Translation is being generated. Please try again later."
こうすれば、ユーザーが状況を理解しやすくなります。
その他のケア策
翻訳品質のフィードバック機能：
「この翻訳、おかしくないですか？」ボタン
→ 読者が誤訳を報告
→ 著者に通知
→ 改善につながる
段階的な翻訳オプション：
[ ] 翻訳機能を有効にする
├─ [ ] 完全自動（著者確認なし）
├─ [ ] 下書きモード（著者が確認してから公開）
└─ [ ] 手動翻訳（AI は使わない）
コミュニティ翻訳の仕組み：
有志が翻訳を改善
↓
著者が承認
↓
公式翻訳として採用
GitHub のプルリクみたいなイメージです。
あとまあ、小まめにこういう翻訳イカれてるぜってのを技術系込みで読み解ける人って本当に本当に本当に貴重枠なので、そういう人と縁出来るのって強みよね、とかまあ副産物的に良いこともあるかもね、とかね。
まあ色々やりようはあるけど、って感じだよね。
どこら辺が落としどころかね～って話。そもそも記事内容が間違っててもツッコミ入れてくれる人とかリアクションしてくる人はそもそも少ないしね。
まあでもあんまり機能増やしすぎても、こう、使いにくくなるよね…というジレンマね。
翻訳されやすい書き方：書き手ができる工夫
機能改善を待つだけでなく、書き手側でもできることがあります。
マークダウンでテキストを書く
画像に説明文を入れ込むのではなく、できるだけテキストとして書く。
これだけで翻訳の精度は上がります。
避けた方がいい：
推奨：
上の図は、○○の仕組みを示しています。
具体的には...
いやだるいな…。
OLTでいいやろ、は機械的には良いけど、人間配慮だるすぎるな…。
シンプルな文構造
複雑な入れ子構造、長すぎる一文は、翻訳が崩れやすいです。
避けた方がいい：
この機能は、ユーザーが記事を執筆する際に、
特に技術的な内容を含む場合において、その内容を
英語圏の読者にも届けられるようにするために、
AIを活用した自動翻訳を提供するものです。
推奨：
この機能はAI翻訳を提供します。
技術記事を英語圏の読者にも届けられます。
私みたいな長いですます+口語はまあ最悪なんですよね。
だからオフってるんですけど。
とはいえ、だよねぇ。
説明系ってどうしても1文が長くならざるを得ない時あるじゃ～んみたいな。
スラングや独特な表現は控えめに
「ぬるっと」「サッと」「エモい」みたいな表現、翻訳が難しいです。
どうしても使いたいときは、補足を入れるのも手です。
ぬるっと（スムーズに、という意味）成功しました。
やってらんないな！？
日本語が難易度高いところ出てるよ…。
これはまあ逆に、英語でのビジネススラングとかいうのもあるのでお互いさまなんですけどね。
というか、こういう事意識しながら書くのいやすぎるな…AIに添削してもらっても良いですけど……。
重要な情報はテキストで必ず記載
画像はあくまで補足。本質的な情報は、テキストでも書いておく。
これなら、画像が翻訳されなくても、最低限の情報は伝わります。
プラットフォームとして発展の余地
Zennは「縁作りサービス」としても、まだまだ発展の余地があると思います。
グローバルなコミュニティへ
自動翻訳機能が改善されていけば、日本語話者と英語話者がもっと自然に交流できるようになります。
技術的な知見に国境はありません。あの中国さんですら、Githubへのアクセスは許可が出るくらいです。
日本のエンジニアが書いた記事が、世界中の人に読まれる。逆に、海外の記事が日本語で読める。
多言語対応の先にあるもの
英語だけじゃなく、中国語、韓国語、スペイン語...
将来的には、もっと多くの言語に対応できるかもしれません。
特に東アジア圏では、「日本語の方が英語より学校で勉強したから読みやすい」という人もいます。
特に中国韓国勢は学校で勉強した、とか
選択で～とか
英語は就職で必須だし、どうせなら日本語も勉強しておいた方が就職先広がるから自分の興味のあるものの選択の一つで、とか
全然意味わからんけど、そういう彼ら特有の需要(多くはないけどね)もあったりします。
あとアニメ見てると怒られるけど、日本語の記事とか論文読んでたら「息抜きでも勉強だからって言えるからｗｗ」ってのも言ってて面白かったです。
ちいかわの記事ってバレて怒られたらしいけど。
学び：プロダクト開発の難しさ
この一連の出来事から、私は改めても含めて学びが多かったなあ、と思います。
全員を満足させるのは不可能
どんな機能追加でも、喜ぶ人もいれば、嫌がる人もいます。
重要なのは、「どちらか一方に決める」ことではなく、適切に選択肢を提供することだと思います。
プロセスの透明性
機能自体の良し悪しとは別に、どう導入するかも重要だな、と。
- 事前告知はあったか(これはわからん。私が追えてないだけかもだけど。)
- ユーザーの声を聞いたか(実装時はわからんけど、オフ対応としては聞いてた)
- ベータテスト期間はあったか(いつごろまで、って言及なかったよね)
- フィードバックを受け付けているか(これはあった)
Zennの場合、午後16時にリリース発表、日付が変わるころにはデフォルトOFFへ変更。この対応の速さは素直に評価すべきだと思います。
華金の夜、おそらく批判の声が予想以上に多かったのでしょう。
すぐに設定を変更して、ユーザーに選択権を戻した。
この柔軟性と誠実さは、プラットフォームへの信頼につながります。
改めて、良かったな、って思いますし、私は少なくとももう少しZennにお世話になっても良いかとなりました。
場を借りてる側ですが、去るのも残るのもこちらの選択ですしね。
エンジニアの皆さん、週末前の緊急対応、本当にお疲れ様でした。
コミュニティとの対話
撤退者が出たのは事実です。これは残念なことですが、同時に貴重なフィードバックでもあります。
「なぜ離れたのか」を理解し、改善につなげる。
これがプロダクト開発の本質ですよね。撤退の判断とかもですけど。
好きなプロダクトなので、大事にしてほしいですけど。
実験の価値
「やってみなきゃわからない」は真実です。
でも、実験するにしても：
- リスクを最小化する工夫（ベータ版、段階的展開）
- ユーザーへの説明（なぜこれをやるのか）
- フィードバックループの確立
これらを組み合わせることで、より良い実験ができます。
段階的展開をまあだいぶ今回すっ飛ばしちゃったよな、と思います。
私の立場：応援しつつ、様子見
最後に、私個人の立場を書いておきます。
とりあえずOFFにしました
理由は：
- 英語記事は自分で書く派(というか元から書いてたし)
- ニュアンスコントロールしたい
- AEO（SEO実験）的な理由もある
でも、これは私の選択であって、正解ではありません。
でも可能性は感じている
グローバル展開、国際交流、知見の共有。
方向性としては、すごく良いと思います。
技術的な課題や、プロセスの問題はありますが、それは改善できることです。
がんばれZenn
ベータ版として、色々試行錯誤するのは当然です。
ユーザーの声を聞きながら、より良い機能に育ててほしい。
私たちユーザーも、建設的なフィードバックを送ることで、一緒に良いプラットフォームを作っていけたらいいなと思います。
せっかくコミュニティ系のサービスだしね、という。
おわりに
Zennの自動翻訳機能、賛否両論あって当然です。
でもこれ、「正解がない問題」なんですよね～っていう。
- 効率化したい vs コントロールしたい
- 実験したい vs 慎重にやりたい
- グローバル化したい vs ローカルの良さを守りたい
どれも正しい。だからこそ、難しい。
重要なのは：
- お互いの立場を理解すること
- 建設的な提案をすること
- 試行錯誤を許容すること
- フィードバックを送ること
プロダクト開発は、完成することはありません。常に改善し続けるプロセスです。
Zennがこれからどう進化していくのか、楽しみに見守りたいと思います。
まあ、またポンコツしたら引っ越しはまた考えるけどな！ユーザーだから！
でも好きで気に入って、ここで書いてるから良いプロダクト開発頑張ってね！！っていうお気持ち。
そして、この記事が「プロダクト開発の難しさ」を考えるきっかけになれば嬉しいです。
プロジェクトマネージャーとかプロダクトマネージャーとか胃痛だけど、エンジニア組もキャリアの一つですしね。
Discussion
この記事を読んで、Zenn に自動翻訳機能が実装されていたことを初めて知りました。
今回の件は、技術的な問題というより 著作権まわりの配慮不足 が大きかったのかなと感じています。
Zenn の規約でも記事の著作権は著者に帰属すると書かれていますし、翻訳は著作権法上「翻案」にあたります。実際に侵害があったかどうかは分かりませんが、作者の許諾なく翻訳が行われ得る仕組みをデフォルトで提供してしまった という点は、さすがにまずかったのでは…という印象でした。
さらに、事前の周知なしでいきなりデフォルト ON で運用開始というのも驚きました。
仮にデフォルト ON にする方針だったとしても、事前告知と実施までにOFFにできる期間があれば、ここまで混乱しなかったはずです。記事ごとに設定できて、対象を新規記事からにするなどの配慮があれば、よりスムーズだったと思います。
公式のお知らせでは「不安にさせて申し訳ない」という表現でしたが、実際の問題は不安というより、著者の権利を侵害し得る状態を作ってしまい、結果としてユーザーに迷惑をかけたことだと思います。その点について、もう少し踏み込んだ説明や謝罪があってもよかったのかなと感じました。
一方で、技術記事にとって静的な翻訳ページがあることは SEO 的に非常に有利なので、機能自体は本来ありがたいものです。ブラウザ翻訳は検索エンジンに評価されませんし、英語圏へのリーチを考えると、正しく権利処理をした上で提供されるなら歓迎したいところです。
また個人的には、Zenn のカテゴリ判定が「コードの有無」に寄りすぎていて、設計・アーキテクチャ・マネジメント系の記事が Idea に分類されてしまう点も気になっています。技術記事の幅を考えると、もう少し内容ベースの分類があると嬉しいですね。
Zenn 自体はとても好きなプラットフォームなので、今回の件をきっかけに、著作権や作者のコントロール権まわりの運用がより丁寧になるといいなと思っています。
コメントありがとうございます～！
お、今回の記事ネタ書くか正直迷ったのですが、書いてよかったです～！
今回はだいぶ思いきった冒険したな～って感じですよねぇ。
権利関係とか再生成の法律的扱いとかはまだまだ議論が必要な印象ですね！
日本の法律や米国での法律などなども絡み合ってきますし…！
本記事内で触れ損ねちゃいましたが、翻訳を許可した結果、ユーザーが誤訳で問題があった時の責任範囲(実装判断したのはユーザーですが、アメリカとかは特に裁判大国ですし)この辺りの問題とかもありますしね。
あ、確かに！カテゴリもものすごく大きな二分割ですしね、今。
私は過去運営側調整をしてもらった事あるので、あると良いかも要素ですね～！
私「Ideaかな～これは」→運営「「Tech」にするね！」という。
逆も体験した事ありますが、まあ場を借りてるし、検索に引っかかりさえすれば良いかのスタンスで最近はこのカテゴリは、運営的に「こっち！」って思ったらしな～ってなりましたね～。
ですね！好きなプラットフォームは長く生き残ってほしいですしね！
｜ユーザーが誤訳で問題があった時の責任範囲
この辺りのさじ加減は難しいですよね。
自動翻訳だけにしておけば言い逃れはできる気もしますが、
手を入れてしまうと境界がずれてくるしね。
著作権の法的な部分は置いておいても、
技術的にも今回のはあまりにも初歩的なミスだと思います。
レビューなしでリリースを急いだのかなって感じです。
オリジナルなのか翻訳なのかは明確にしてもらわないとね。