丁宇 | DING Yu
Google翻訳やDeepLを超える翻訳アプリを作って学んだこと
これは英語で書いたオリジナル記事の日本語訳です（英語版はこちら）。英語で読みたい方はぜひご覧ください。
始まりはこうだった
最近、「Kintoun」という新しいアプリを作りました。これは高品質な翻訳ができて、元のレイアウトもほとんどそのまま保つことができるドキュメント翻訳ツールです。
最初は、そんなに期待していませんでした。でも、Google翻訳やDeepLと比べてみたら、意外と自分のアプリの方が良い結果になることが多くて驚きました。
この記事では、開発しながら学んだことを共有したいと思います。文章にすることで自分の考えを整理できるし、これから何かを作ろうと考えている人にも何か参考になるかもしれません。
レッスン1 驚き：自作アプリがGoogle翻訳やDeepLより良かった
いくつか例を見せますね。
ドキュメント1：元データ
これはMicrosoftのWordドキュメントです：
ドキュメント1：Google翻訳の結果
これをGoogle翻訳で日本語に変換してみました：
Google翻訳ではうまく処理できませんでした。文章が翻訳されていなかったり、レイアウトやフォントも崩れてしまいました。いくつかドキュメントや他の言語でも試しましたが、どれも同じでした。
ドキュメント1：DeepLの結果
次はDeepLで試してみます：
DeepLの方がかなり良い結果でしたが、「Appetizer」など一部の部分が抜けていました。
ドキュメント1：Kintounの結果
最後に、Kintounの結果がこちらです：
Kintounは全てのテキストを正しく翻訳し、レイアウトもきちんと保たれていました。
ドキュメント2：元データ
文書によっては、発音を示すためにふりがな（ルビとも呼ばれます）が付けられていることがあります。
たとえば、日本語の文書では、漢字の上にひらがなでふりがなが振られていることがよくあります。
こちらは、ふりがなが含まれた別のドキュメントです：
ドキュメント2：Google翻訳の結果
これをGoogle翻訳で英語に翻訳してみました：
Google翻訳は、発音ガイド付きのテキストを完全に無視してしまいました。そのせいで、翻訳が抜けて不自然な内容になってしまいました。
ドキュメント2：DeepLの結果
DeepLの翻訳がこちらです：
DeepLはふりがなには対応できましたが、レイアウトが崩れてしまいました。例えば、表内の箇条書きが消えていました。
ドキュメント2：Kintounの結果
Kintounで翻訳した結果はこちら：
Kintounはすべてのテキストをきちんと翻訳し、レイアウトも元通りのままでした。
他にもたくさん例を挙げられますが、これでだいたい分かってもらえると思います。
正直、ちょっと現実感がないです。 自分は本当に下手な素人プログラマーで、どんな本格的な技術面接も受からないだろうし、実際、開発には本業と子育ての合間に2週間くらいしか使っていません。 なのに、どうしてこんな大企業より良いものが作れたのか、不思議で仕方ありません。
でも、とにかく出来ちゃったんですよね。
レッスン2 プロダクト開発と同じくらい、届け方も大事
先日Redditで見かけた投稿が、すごく心に響きました。
いつも同じパターンでした：
- アイデアを思いついてワクワクする
- 何ヶ月もかけて開発する
- リリースしたら誰にも気づかれない
- 落ち込む
- また繰り返し
まさに自分のことだし、同じような個人開発者は多いと思います。
この投稿には、そのサイクルをどうやって抜け出すかも書かれていました：
効果があったこと：
- すでに問題解決を探している人を見つける
- DMを送り付けるのではなく、「誰か○○できるツール知ってますか？」とか「[競合]にうんざりしてる」という投稿を探して、本当に役立つ情報を提供した。
- 最初は売り込みじゃなく、とにかく助けたい姿勢で。自分の最初のメッセージはたいてい相手の質問にきちんと答えること。価値を提供して“から”「実は自分もこんなツール作ってますよ」と紹介する。
私はそれをじっくり読んでから、ずっと心に留めています。同じアドバイスを、Dmytro Krasunさん（screenshotone.comの開発者）からも見つけました：
プロダクトを売る相手が一人も想像できないなら、それは作るべきじゃない。
でも実際には、Kintounをリリースして宣伝を始めるまで、本当の意味では理解できていませんでした。今のところ、プロモーションについてはぼんやりとしたアイデアしかなく、どれがうまくいくのか、具体的にどう進めればいいのかもまだよく分かっていません。
今思えば、アプリ開発と同じくらいの時間をかけて、マーケティング方法を考えるべきだったなと思います。むしろ、開発前にそれをやっておくべきだったのかもしれません。
あるいは、はっきりした販売戦略ができるまで開発を始めないという、昔ながらの「正しい」ブートストラップ流 ― まずはお客さんを集めてから作り始める（“まずは形だけでも見せる”）方が良かったのかもしれません。
レッスン3 Inertia + Svelteはめちゃくちゃ快適
もしかしたら自分だけかもしれませんが、実際にHotwireを本番環境でしばらく使ってみても、正直どう動いているのか、いまだによく分かりません。
例えば：
- どうやって302リダイレクトすればいいんだろう？
- ページ内に点在する5つの要素を、IDを手動で管理せずにリアクティブにするには？
- フォーム送信はどうするのが正解？Turbo StreamとTurbo Frame、両方使うべき？
もちろん、昔ながらにjQuery＋Asset Pipelineも悪くはないです。 実際いまも本業や個人開発ではそれでやってるんですが、ちょっとでもリアクティブなUIにしようとすると、もう地獄です。
いろいろな選択肢を検討した結果、最終的にInertia.jsとSvelteに決めました。 その結果、本当に画期的な変化が起きました。
今では、RailsとAction Cableと連携させながら、従来のSPA特有の面倒なAPI管理や状態管理なしで、すごく簡単に反応の速いUIを書けるようになりました。
SvelteはエコシステムがReactより小さいけど、作るのは圧倒的に楽で速いです。
もしまだ試してなかったら、ぜひおすすめです：
- Inertia-Rails：Railsとフロントエンドフレームワークをつなぐツール
- Svelte：Reactより簡単
- livestores：Action Cable を使ってサーバーの状態をフロントエンドにプッシュする
最後に
Kintounを作るのは、今までやってきたプロジェクトの中でも特に楽しい経験でした。 ほかのサイドプロジェクトと違って、今回は妻からすぐにリアルなフィードバックをもらえたんです。
妻はKintounをすごく便利だと言ってくれて、仕事で使っている高額な翻訳サービスよりもいいってまで褒めてくれました。 そういう率直な反応がもらえると、自分が作ったものを身近な人が実際に気に入ってくれているのがわかって、すごくやりがいを感じます。
一方で、まだどうやったらもっと多くの人に知ってもらって使ってもらえるか、模索中です。 それが次のチャレンジですが、その過程も含めてこの旅路の一部だと思うと、これからもワクワクしながら続けていきたいです。
読んでくださってありがとうございます。もし興味があれば、Kintounをぜひチェックしてみてください。あなたにも役立ててもらえたら嬉しいです。ご意見やご感想があれば、ぜひ聞かせてください。