better-authが認証のためにやったことを、better-i18nはローカライゼーションのためにやっている

「better-」哲学がどのように開発者ツールを再形成しているか — そして、なぜi18nはとっくに同じ扱いを受けるべきだったのか。

NextAuth.jsやAuth.jsに苦労した後でbetter-authを使ったことがあるなら、あの感覚を知っているはずです。ライブラリが単に動くだけでなく — 正しいと感じる瞬間。APIに意味がある。TypeScriptの型が完全だ。ドキュメントがまさに疑問に答えている。ツールと戦うのをやめ、プロダクトを構築し始める。

その感覚がbetter-i18nを生み出しました。

これはマーケティングの文章ではありません。ローカライゼーションにおける開発者体験が何年も停滞してきた理由、「better-」哲学がi18nにどう適用されるか、そしてそれが実際に何を意味するかについての正直な考察です。

better-authの効果

better-auth以前、Next.jsの認証状況はこんな感じでした：

• NextAuth.js / Auth.js — デフォルトの選択。強力で広く採用されているが、悪名高い複雑な設定、一貫性のないTypeScriptサポート、多くのチームを困らせたv4からv5への移行。
• Clerk, Auth0, Supabase Auth — プロバイダーが想定していなかった何かをカスタマイズする必要が出るまでは素晴らしく機能するマネージドサービス。
• 自分で作る — シンプルに始まりセキュリティインシデントで終わる「とりあえずbcryptとJWTを使う」アプローチ。

そこにbetter-authが現れてこう言いました：もし認証がシンプルで、型安全で、2025年に開発者が実際に働く方法のために設計されていたら？

結果は、爽やかなほど明快に感じられるライブラリでした。最初から完全なTypeScriptサポート。制約する代わりに拡張するプラグインシステム。セキュリティプロトコルの博士号を必要としないセッション管理。ただ接続するデータベースアダプター。ただ動くソーシャルログイン。

開発者がbetter-authに乗り換えたのは、機能が多かったからではありません。彼らの時間を尊重してくれたからです。

i18nの問題は同じ問題

今度はローカライゼーションの状況を見てみましょう：

• react-i18next / i18next — 業界標準。実戦で鍛えられ、信じられないほど柔軟だが、かなりのボイラープレートが必要。型安全性は後付け。App Routerを使ったサーバーサイドレンダリングには慎重な手動設定が必要。すべてのプラグインとオプションの学習曲線は本物。
• next-intl — Next.js専用として大幅な改善。クリーンなAPI、素早いセットアップ。しかしNext.js限定。React Nativeなし。Vueなし。Astroなし。そしてJSONファイルはまだ手動で管理。
• Crowdin, Lokalise, Phrase — 月額40〜385ドルからの価格帯のマネージドプラットフォーム、企業の調達サイクル向けに設計された不便なWebインターフェース、ファイルのエクスポート・アップロード・待機・ダウンロード・再インポートを含む開発者ワークフロー。

見覚えがありますか？同じパターンです：

両方のケースで欠けていた選択肢は？デフォルトでシンプル、必要なときに強力、全体を通じて型安全な開発者ファーストのツール。

better-i18nが「Better」哲学をどう適用するか

名前は偶然ではありません。私たちはbetter-authから明示的にインスピレーションを得ました — 命名だけでなく、設計哲学においても。それがどう転換されるかを説明します：

1. 型安全性はオプションではない

better-authは@typesパッケージで後から追加するのではなく、TypeScriptサポートをコア機能にしました。better-i18nは翻訳キーに対して同じことをします。

// すべてのキーが型付き。オートコンプリートが動作する。タイポはコンパイル時に検出される。
const t = useTranslations();
t("hero.title");     // ✅ オートコンプリートがこれを提案
t("hero.ttle");      // ❌ TypeScriptエラー — キーが存在しない

i18nextの世界では、部分的な型安全性を得るために追加の設定、カスタム型宣言ファイル、プラグインが必要です。better-i18nでは、それがデフォルトです。

2. 可能な限りゼロコンフィグ、必要な場所では完全な制御

better-authは数行のコードとデータベースアダプターで始めることができます。複数ファイルの設定儀式なし。

better-i18nも同じ原則に従います：

• CDN配信は即座に機能する。 ビルドステップの設定なし。翻訳を公開すれば、数秒でグローバルにライブになります。
• キー検出は自動。 CLIがAST解析でコードベースをスキャンします。すべてのキーを手動でリストアップする必要なし。
• Git同期はネイティブ。 翻訳はプルリクエストとして届きます。エクスポート/インポートのダンスなし。

でも制御が必要なときはそこにあります。エンタープライズ向けカスタムAIモデル。オンプレミスデプロイ。細粒度の権限。プラグインベースのSDKアーキテクチャ。

3. 5つではなく1つのツール

better-authは「NextAuth + Clerk + カスタムミドルウェア + セッションストア + ソーシャルログインアダプター」スタックを一つの統合されたライブラリで置き換えました。

better-i18nは「react-i18next + Crowdin + カスタム抽出スクリプト + CDNセットアップ + 型生成ツール」スタックを一つの統合されたプラットフォームで置き換えます：

4. AIネイティブの違い

ここでbetter-i18nはbetter-authが解決する必要があったことを超えます。認証にAIは必要ありません。ローカライゼーションには切実に必要です。

従来の翻訳ワークフロー：

1. 開発者がキーを抽出
2. 開発者がJSONファイルをエクスポート
3. PMが翻訳プラットフォームにアップロード
4. 翻訳者が翻訳（数日〜数週間）
5. PMが翻訳済みファイルをダウンロード
6. 開発者がインポートしてコミット
7. PRレビュー、マージ、デプロイ
8. 各言語更新ごとに繰り返し

better-i18nのAIネイティブワークフローでは：

1. 開発者がコードを書く（キーは自動的に検出される）
2. AIがブランドコンテキストと用語集マッチングで翻訳
3. 翻訳者がレビューして承認（または信頼できる言語は自動承認）
4. 即座にCDNでライブ

ステップが8から4に削減。カレンダー時間が週から時間に。

MCP（Model Context Protocol）統合により、ClaudeやCursorから直接翻訳を管理できます：

「ねえClaude、ブランドボイスの用語集に合わせて、新しいオンボーディングフローをドイツ語とフランス語に翻訳して。」

他のどのローカライゼーションプラットフォームもこれを提供していません。すでにAIで作業している開発者のために構築するとこうなります。

正直な比較

「better-」プレフィックスには責任が伴います：特定のユースケースで実際に優れていなければならない。better-i18nが本当に優れているところ — そして代替品が勝つところ：

better-i18nが勝つところ

代替品が勝つところ

正直な答え： 成熟した翻訳パイプラインを持つ既存のi18next設定がある場合、better-i18nへの移行は移行コストに見合わないかもしれません。しかし、新しいプロジェクトを始めている場合や、現在のワークフローがサービス間でJSONファイルを手動で移動することを含んでいる場合、「better-」アプローチは大幅な時間節約になります。

開発者ツールにおける「Better」パターン

better-authとbetter-i18nは、より広いトレンドの一部です：不必要な複雑さを現状として受け入れることを拒否する開発者ツール。

パターンはこのようなものです：

1. 既存プレーヤーが支配する ファーストムーバー優位とコミュニティ慣性によって（NextAuth、react-i18next）
2. 痛みのポイントが蓄積される が「物事はこういうもの」として受け入れられる（複雑な設定、貧弱な型、手動ワークフロー）
3. 新しいツールが現れる 現代的な仮定でゼロから始める（TypeScript-first、AIネイティブ、Gitネイティブ）
4. アーリーアダプターが移行する 新しいツールに機能が多いからではなく、フラストレーションが少ないから
5. エコシステムがシフトする 新しい標準がすべての人の期待を引き上げるとき

これを見てきました：

• Prisma が生のSQLクエリビルダーを置き換える
• Tailwind がCSS-in-JSの複雑さを置き換える
• Vite がwebpackの設定の苦痛を置き換える
• better-auth がNextAuthのフラストレーションを置き換える
• better-i18n が翻訳ファイルのシャッフルを置き換える

共通のテーマ？開発者体験はあったらいいものではありません。それがプロダクトです。

始めてみる

i18nに対する「better-」哲学がどのような感じかを体験したい場合：

クイックスタート（5分）

# SDKをインストール
npm install @better-i18n/react

# Next.jsの場合
npm install @better-i18n/next

// アプリをラップする
import { I18nProvider } from "@better-i18n/react";

function App() {
  return (
    <I18nProvider project="your-project" locale="en">
      <YourApp />
    </I18nProvider>
  );
}

// どこでも翻訳を使用
import { useTranslations } from "@better-i18n/react";

function Hero() {
  const t = useTranslations();
  return <h1>{t("hero.title")}</h1>;
}

無料プランには1,000キーと2言語が含まれます — アプローチが自分に合うかどうかを評価するには十分です。

最後に

better-authは、認証がシンプリスティックにならずにシンプルになれることを証明しました。型安全性が後付けではなく、組み込みにできることを。開発者体験は設計する価値があることを。

better-i18nは同じ賭け、ローカライゼーションに適用されたものです。i18nエコシステムが同じ「better-」な扱いを受けるべきだと思っています — そして、これまでの反応を見ると、そう思っているのは私たちだけではありません。

i18nextの設定ファイルをじっと見ながら「なぜこんなに複雑にならなければならないのか」と思ったことがあるなら、なぜこれが存在するのか理解できるでしょう。

better-i18nを無料で試すか、ドキュメントを読んでください。すでにbetter-authを使っているなら、すぐに家にいるような感覚になるはずです。