業務システムでMAUI・WPF・WinUI・Avalonia・Unoなどの.NETクライアントを開発していると、多言語対応の管理が後回しになりがちです。英語の.resx（リソース文字列を格納するXMLベースのファイル）は整備されていても、スペイン語版やフランス語版に未翻訳キーが溜まっていく状態に心当たりのある方に向けて、NuvLocというツールの仕組みを整理します。
翻訳ベンダーのAPIキーを契約するほどの規模ではないが、IDE付属のリソースマネージャーだけでは限界がある、という中間規模のプロジェクトは意外と多いはずです。NuvLocはその隙間を狙ったCLIツール（コマンドラインから操作するツール）で、翻訳作業そのものはAPI連携せず、既に使っているコーディングエージェント（AIによるコード生成支援ツール、例えばCursorなど）に委ねる設計になっています。
NuvLocが解決する問題の輪郭
NuvLocはNuGet（.NETのパッケージ配布サービス）上で配布されるグローバルdotnetツールです。パッケージ名はNuvyntraLabs.NuvLoc.Cliで、バージョン1.1.2が公開されています。
重要なのは、これがプロジェクトにPackageReferenceとして組み込まれるライブラリではない点です。XAMLに文字列をバインドする機能も持ちません。
役割は明確に分離されています。英語の.resxを基準に、どの言語のどのキーが未翻訳かを検出し、その差分をエージェントに渡す。翻訳の生成自体はOpenAIやAzureのAPIを一切呼び出さず、CLIは「検査係」に徹しています。
仕組みを段階的に見る
まずインストールです。
dotnet tool install -g NuvyntraLabs.NuvLoc.Cli --source https://api.nuget.org/v3/index.json
nuvloc versionグローバルツールとしてインストールするため、特定のプロジェクトに依存せず、複数リポジトリで使い回せます。社内で共通の多言語運用ルールを持つ組織であれば、CI環境のベースイメージに組み込んでおくのも選択肢になります。
次に設定ファイルi18n.jsonをプロジェクトルートに置きます。
{
"platform": "maui",
"source": "Resources/Strings/AppResources.resx",
"languages": ["es", "fr"]
}platformにはmaui・wpf・winui・avalonia・unoのいずれかを指定します。sourceは基準となる英語の.resxパスです。
languagesには翻訳対象の言語コードを列挙します。ここでBCP-47（言語タグの国際標準規格、esやpt-BRのような表記）に準拠しているかがチェックされます。
表記ゆれは自動で正規化されます。たとえばPT-brと書いてもpt-BRに補正されます。一方でアンダースコア表記のes_MXや、英語自体を示すen・en-USは拒否され、CLIは終了コード2を返してエラー理由を表示します。
テスト済みの言語コードとしてes・fr・de・it・nl・ja・ko・zh-Hans・pt-BR・ar・hi・ruが挙げられています。日本語プロジェクトであればjaを含めて動作確認しておくとよさそうです。
設定後はnuvloc init --configfile i18n.json --agent cursorでエージェント向けのスラッシュコマンドを準備します。ここから先、実際にAppResources.es.resxのようなカルチャファイルを書き出すのはCLIではなくエージェント側です。CLIは翻訳結果に対して、キーの網羅性チェックと{0}のようなプレースホルダーの整合性チェックを担当します。
CI（継続的インテグレーション）に組み込む際はnuvloc check --ciを使います。このコマンドはエージェントを必要とせず、既存の.resxファイル群が仕様を満たしているかだけを機械的に検証します。
既存の多言語対応手法との比較
.NET開発における多言語対応は、これまで大きく二つの流れがありました。ひとつはVisual Studioのリソースエディタで手作業管理する方法、もうひとつはクラウド翻訳管理サービス（Crowdin・Lokaliseなど）にAPI連携して外部ベンダーに依頼する方法です。
前者はコストがかからない代わりに、キーの追加漏れや翻訳漏れを人力でしか検出できません。後者は精度と運用体制が整う一方、API契約やベンダー選定のコストが発生し、小中規模の業務アプリには過剰投資になりがちです。
NuvLocはこの中間に位置します。翻訳生成はコーディングエージェントに任せる分、外部翻訳APIの契約は不要です。その代わり、CLIが「機械的に検査できる部分」だけを責任範囲として明確に切り出しています。
この設計思想は、AIエージェントを業務コードに組み込む際の一般的な考え方とも重なります。生成そのものはLLM（大規模言語モデル）に任せつつ、検証は決定的なロジック（毎回同じ結果になる処理）で行うという役割分担です。翻訳の「意味が正しいか」はAIの得意領域ですが、「キーが漏れていないか」「プレースホルダーの数が合っているか」は機械的に判定できる領域だからです。
導入前に確認したいポイント
実際に検討する際は、以下の観点をチェックすると判断しやすくなります。
- 対象のUIフレームワークが
maui・wpf・winui・avalonia・unoのいずれかに該当するか（WinUI・UnoのPRI形式.reswは現状スコープ外） - 既存の英語
.resxが単一ファイルとして整理されているか（カルチャファイルは同名の.es.resxのように隣接配置される前提） - CI環境に既にコーディングエージェントを組み込んでいるか、もしくは
--agent cursorのような形で対応しているエージェントを利用しているか - 翻訳対象言語がBCP-47準拠で表記できているか（
es_MXのような独自表記を使っていないか）
特に重要な注意点として、公式ドキュメントでも明記されている通り、カバレッジチェックとプレースホルダーチェックは「キーが揃っているか」「変数の数が一致するか」しか保証しません。文章として自然かどうかは別問題です。
業務システムの多言語対応では、法務文書や契約関連の文言など、誤訳が業務リスクに直結する箇所もあります。自動化できる部分と人手レビューが必須な部分を最初に切り分けておくことが、運用を破綻させないコツです。
まとめ
NuvLoc 1.1.2は、翻訳API契約なしに.NET系マルチプラットフォームアプリの多言語リソース管理を効率化するCLIツールです。
確認すべきことを整理すると次の通りです。
- 対象プラットフォームが
maui・wpf・winui・avalonia・unoのいずれかであること i18n.jsonでsourceとlanguagesをBCP-47準拠で設定できることnuvloc check --ciをCIパイプラインに組み込み、エージェント生成後の検証を自動化すること- 検査対象はキーの網羅性とプレースホルダー整合性のみであり、文章の自然さは別途レビュー体制が必要なこと
まずは既存プロジェクトの.resx構成が対象プラットフォームの前提を満たしているか、リポジトリを見て確認するところから始めてみるとよさそうです。