OSS日本語化の本家還元（アップストリームPR）

OSSの日本語化や修正を本家へPRとして返す実践を、キット販売・還元状態の4類型とともに整理する概念。

定義

oss-japanese-localization の作業を、自分の環境で満足させて終わらせず、翻訳ファイルや実装を本家（アップストリーム）へ還元するまでの一連の実践を指す。上流還元の一般論を「日本語」という具体的な不足領域で実行する行為であり、oss の理念の適用例でもある。

セルフホストしたOSSを使うだけでは、翻訳は自分のサーバーの中に閉じる。本家へ返すことで、次に同じOSSを導入する日本語話者が何もしなくても日本語で使えるようになる。この概念は、その一回分の手間を肩代わりする設計だと位置づけられる。

典型的な流れ

1. 立てる — Docker等でOSSをself-hostingとして起動し、実際に業務で使う
2. 日本語の穴を見つける — 画面の未翻訳、翻訳済みでも崩れる表示、検索が効かない等の不具合を実測で洗い出す
3. 訳す — 翻訳キーを全量または不足分だけ日本語化する（Weblate等の翻訳基盤を使う場合もある）
4. 実装してビルドを通す — フロントエンドの言語ファイル追加、必要ならコンパイルまで通す
5. 本家へPRを送る — 翻訳ファイル・キット・手順を上流に提案する
6. 導入ガイドを書く — 日本語で使うための手順を記事化し、再現可能にする
7. キットとして束ねる — 手順書・設定・検証スクリプトを一式にし、AIエージェントが読める形にして配布・販売する

このうち 1〜2 が「使う」段階、3〜5 が「返す」段階、6〜7 が「次に使う人の手間を消す」段階にあたる。

索引文書から見える具体例

kurage-articles-index は Kurage の記事 全600本（収録期間 2026-05-18〜2026-10-24）を1行ずつ「タイトル [topics: タグ列] → URL」の形式で並べた索引であり、その大半は日次の ai-news シリーズが占める。OSSの日本語化・還元に関する記事群は 2026-08 から 2026-09 にかけて、しかも 9月上旬（09-01〜09-07）に密集 しており、20本前後と全体のごく一部でありながら、対象OSSごとに「どこがどれだけ欠けていたか」が数値つきで残されている。

• Zammad — ヘルプデスクOSSの日本語が 23% しかなかった。5,123エントリを全訳し、本家Weblateを100%にするまでを記録
• krayin-crm-japanese-kit — スター2.3万のCRMに日本語がなかったため、全キー（索引では 2,066キー、商品ページでは 2,392キー と記載）を訳して本家にPR提出中
• vikunja-japanese-kit — タスク管理OSS。翻訳の穴 9%（135キー） を埋めて本家に返した
• docspell-japanese-kit — 日本語が一切ない書類管理OSS。画面 1,056語 を訳し、Elm で実装してコンパイルを通すまで
• planka-japanese-kit — カンバンOSS。翻訳の穴 56キー と、ライセンス上の線引き（第三者向けホスティングは有料）を同時に確認
• docmost-japanese-kit — 社内Wiki。翻訳100%でも残る問題を報告
• twenty-crm — スター5.5万のSalesforce代替CRM。実際に構築して分かった 日本語検索の穴 と、触れるデモを公開
• docuseal — 電子署名基盤。Docker 1行で立て、署名する相手に日本語画面が届くことをコードで確認
• openvpm — 動物病院の電子カルテ。英語のみだった画面を日本語化し、紙カルテの移行（和暦・Shift_JIS）まで本番構成で確かめた。本家とは提携しない非公式の日本語版（AGPLv3）
• fess — 日本発の全文検索OSSをDockerで立て、45本のPDFを索引し、ローカルLLMで10問実測
• alaveteli / fixmystreet — 情報公開請求・道路通報システムを日本語化して動かし本家にPR
• theyworkforyou — 英国議会の議事録OSSを日本の国会会議録で動かし、日本語が1件も引けないXapianの関門と5つの修正を記録
• codealmanac-japanese-kit — macOS専用だったため Linux対応（systemd） を実装して本家に送った、翻訳以外の還元例（PR提出済み）
• appsmith — 初回起動を20秒中断すると永久に壊れる罠を突き止め、データを消さずに直した運用事例
• paperless-ngx — 定番の jpn+eng OCR設定が見出しを壊す実測と、日本語で自動分類を効かせる正解
• libredesk-japanese-kit — 本家の日本語は 25か所が画面で壊れており、修正済みの翻訳 1,536項目 を同梱。ただし翻訳がバイナリに埋め込まれているため、公式イメージのままでは日本語が使えない

周辺のキット群（espocrm-japanese-kit、freescout-japanese-kit、billionmail-japanese-kit、decap-cms-japanese-kit、kouchou-ai-local-kit、pdfmathtranslate-japanese-kit）も同じ構図で並ぶ。

索引は「圧縮された記録」である

索引の1行はタイトル・タグ・URLしか持たないため、翻訳キー数や実測値のような定量的な主張は必ず各記事本文で確認する必要がある（Krayin のキー数が索引と商品ページで食い違うのがその例）。またタグは記事群によって表記が揺れており、初期の記事は日本語タグ（個人開発、生成ai、業務効率化）、日次ニュース群は英語5点セット（ai、llm、vibecoding、web3、startup）が機械的に付く。タグ検索だけでは還元記事を拾いきれないのは、この揺れも一因になっている。

還元がキット・商品として流通する

kurage-products は、これらの還元作業が最終的にどこへ着地するかを示している。日本語化したOSSの導入手順・設定・検証スクリプトは 5,500円のキット として kurage-app-store に並び、ソースコード同梱・MITライセンス・月額なしで配布される（kappstore-ecosystem）。還元（本家へのPR）と、キットの配布・販売は別の行為であり、片方をしても片方は自動では起きない。

商品ページには還元の状態そのものが明記される。Krayin CRM は「本家へプルリクエスト提出中」、CodeAlmanac は「Linux対応を実装し本家PR提出済み」、EspoCRM・FreeScout・Decap CMS は「日本語UIが公式配布に同梱」と書かれる。つまり商品カタログは、日本語化の進捗を外向けに示すもう一つの索引としても機能する。

還元の状態は4つに分かれる

商品ページと索引を突き合わせると、上流との関係は一枚岩ではなく、少なくとも4つの状態に整理できる。

この整理は「PRを出したか否か」だけでは語れないことを示す。返せる相手・返せない相手がいることが、キットという商品形態を成立させている面がある。

キットの多くは「デモを触ってから購入」の形をとり、動く画面そのものを証拠として公開する。saas-subscription-replacement を狙う商品でありながら、還元した翻訳は本家に返してあるため、買わなくても日本語で使える状態が広がっていく。この重なりが、この分野の事業の特徴になっている。

重要な発見

翻訳100%でも「日本語で使える」とは限らない

最も繰り返し現れる論点。Docmost の記事では、翻訳が100%に達していても日本語検索に穴があることが報告され、その対策まで踏み込む。Twenty CRM でも同様に、構築して初めて見える日本語検索の穴が主題になっている。訳語を埋める作業と、検索・ソート・正規化といった言語処理の挙動を直す作業は別物であるという認識が共有されている（japanese-search-gap）。

上流に返せない構造がある

LibreDesk は「翻訳がバイナリに埋め込まれている」ため、公式イメージのままでは日本語が使えない。Appsmith に至っては翻訳の仕組み自体が存在せず、文言 1,397件が直書き・言語ファイル0本 と実測されている。こうした相手では、PRを出すという行為そのものが成立せず、キットに翻訳を同梱して配るしかない。

逆に、paperless-ngx の OCR 設定のように「3か所直さないと日本語が読めず、しかも2か所は間違えてもエラーが出ない」問題は、上流のコードではなく利用者側の設定で解く話である。何を本家に返し、何をキットの手順書に書くかという仕分けが必要になる。

「訳して終わり」にしないために実測を添える

• whisper.cpp は47秒の会議音声を27秒・文字誤り率2.7%で処理
• Fess は検索10/10・回答9/10
• PDFMathTranslate は15ページを3分・費用0円、ただし思考型モデルで5.8倍遅くなる罠つき
• OpenVPM は紙カルテの移行（和暦・Shift_JIS）まで本番構成で確認
• TheyWorkForYou は2026年6月の25会議・1,397発言を取り込み、日本語で全文検索できるところまで実測

数値が添えられることで、還元した翻訳や設定が実際に業務で使える品質かが読者に伝わる。これらの落とし穴は measured-pitfall-catalog として横断的に蓄積されている。

上流に返す範囲は翻訳だけではない

• 言語ファイルの追加（多くのキット）
• OS対応の追加（CodeAlmanac の Linux／systemd 対応）
• 破壊的挙動の修正（Appsmith の初回起動問題）
• 検索基盤の修正（TheyWorkForYou の Xapian 日本語索引）
• 導入ガイド・キット・AIエージェント向け設置指示書の整備

なぜ本家に返すのか

1. 再発明の回避 — 次に同じOSSを導入する人が同じ翻訳をやり直さなくて済む
2. 維持コストの移譲 — 本家に取り込まれれば、以後のアップデートで翻訳が壊れにくくなる
3. 信用の形成 — 上流への継続的な貢献は、oss を軸に事業を展開する主体にとっての競争優位につながる
4. 差分の縮小 — フォークを抱え続けるより、本流に寄せた方が長期的に安い（oss-vendoring の判断と表裏）

実践上の注意

• ライセンスの確認 — Planka のように「第三者向けホスティングは有料」といった線引きがある。翻訳を返すことと、そのOSSをサービスとして再提供することは別の判断。取り込む本家のライセンスも揃わない（TheyWorkForYou は BSD 3条項、Alaveteli・OpenVPM・広聴AI は AGPL、Krayin・Planka 等は MIT）。キット自体が MIT でも、本体の条件は別に及ぶ（open-data-license-compliance と同じく、配布条件をコードと文書に固定しておく）
• 公式同梱と非公式版の区別 — EspoCRM・FreeScout・Decap CMS は日本語が公式配布に同梱されるが、OpenVPM の日本語版は本家と提携しない非公式版である。どちらの立場で配るかを明確にする
• ビルドが通る形で返す — Docspell の Elm のように、言語ファイルの追加がコンパイルを要求する場合がある
• 返せない相手はキットで吸収する — Appsmith・LibreDesk のように差し込み口が無い場合は、同梱した翻訳と手順を商品の中心に据える
• 実測を残す — 翻訳キー数、欠けていた割合、動作確認の結果を記事やキットに含める
• 索引の数値を鵜呑みにしない — kurage-articles-index の1行は要約であり、キー数などは記事本文・商品ページと突き合わせる
• 日次ニュースと混同しない — 索引全600本の大半は ai-news シリーズであり、日本語化・還元の記事は 2026-08〜09 の限られた期間に集中する

関連

• oss-japanese-localization — 日本語化そのものの作業
• oss — OSSを前提とした事業・開発の姿勢
• oss-vendoring — フォークを抱えるか本流に寄せるかの判断
• self-hosting — まず自分のサーバーに立てる段階
• japanese-search-gap — 翻訳100%でも残る検索の穴
• measured-pitfall-catalog — 実測した落とし穴を横断的に蓄積する形式
• open-data-license-compliance — ライセンス条件を配布物に固定する考え方
• kappstore-ecosystem — 還元した成果がキットとして並ぶ配布基盤
• saas-subscription-replacement — キットが置き換えを狙う対象
• local-llm — Fess や PDFMathTranslate の実測で使われるローカル推論
• rag — 全文検索OSSと組み合わせた「聞けば答える」構成
• ai-readable-manual — 導入手順を記事・キットとして残す考え方
• kurage-articles-index — 本概念の根拠となる記事索引（全600本）
• kurage-repos / kurage-products — 還元対象となったOSS群と、その配布商品としての位置づけ

See also: kurage-sites