aoisensi.info

最近Valveのゲームに追加された公式日本語訳からくるモヤモヤとした気持ち

Wed, 08 Apr 2026 00:00:00 GMT

Dota2と公式日本語訳

今から約1年ほど前、あれは確か2025年2月7日にDota2というゲームに公式の日本語訳が追加されました。

自分は10年以上前からこのDota2というゲームを遊んでいます。

この記事を書いているときにはプレイ時間は9621時間となっております。

もうすぐで5桁時間ですね。

さて、このDota2というゲームを作ったValveという会社、皆さんも御存知Steamを運営しているところなのですが。

今までは一部の国を除くほとんどのローカライズをボランティアを募集して翻訳作業をさせていました。

ストーリーが重要な一部のゲームは外部のゲーム専門のローカライズチームに委託していたのですが、Dota2は長らくボランティアによる翻訳でした。

つまり、今までDota2の日本語版は素人による翻訳だったのです。

Dota2非公式日本語MOD

しかし、自分は活発に更新されない準公式日本語版に嫌気が差していました。

幸い、自分には多少のプログラムの知識があり、Source Engineの仕様もある程度認知していたので完全非公式の日本語化MODを作る決意をしました。

そしてそれは実りました。

そしてこのMODの更新は今でも続いています。

あれ、公式日本語訳が出たのに非公式の翻訳作業が必要なんですか？

つづく...

公式日本語化のただの感想

つづき...

もし、あなたが好きなゲームやメディアが今までボランティアによる翻訳しかなかったのに突然公式が翻訳を追加したらどう思いますか?

喜びますよね?

ですが、今回の公式日本語訳が自分の心に生み出したのは悲しみでした。

翻訳がモヤモヤする理由

それは、明らかに翻訳者がゲームに対するリスペクトを一切持っていないと感じたからです。

それどころか翻訳者はまともにゲームをプレイしたことがないでしょう。

日本語を英語に翻訳する、という作業はかなりよくできています。プロの仕業でしょう。

しかし、明らかにこのゲームとマッチした訳し方ではないところがこれでもかと見つかります。

いくつか紹介しましょう。

なお、下に行くほど自分のエゴが強くなっていきます。

1. 一部のヒーロー名の翻訳を失敗して放置されている

Anti-Mage, Lina, Kunkka, Queen of Pain

これらの4体のヒーローは公式日本語訳が追加された当初から英語のまま放置されています。

正確には、翻訳ファイルに日本語の名前と英語の名前を記述する欄があるのですが、この5体はそれを逆さまに書いています。

ゲームデータ内の翻訳ファイルを一部引用してみます。

    // Hero Names
    // The "__en" versions are for the "Classic Hero Names" option.  These are still separate tokens for languages that want to add compatibility annotations
    "npc_dota_hero_none:n"                           "--"
    "npc_dota_hero_none__en:n"                       "--"
    "npc_dota_hero_queenofpain:n"                    "Queen of Pain"
    "npc_dota_hero_queenofpain__en:n"                "クイーン・オブ・ペイン"
    "npc_dota_hero_antimage:n"                       "Anti-Mage"
    "npc_dota_hero_antimage__en:n"                   "アンチメイジ"
    "npc_dota_hero_antimage_persona1:n"              "Anti-Mage (Wei)"
    "npc_dota_hero_antimage_persona1__en:n"          "アンチメイジ （ウェイ）"
    "npc_dota_hero_kunkka:n"                         "Kunkka"
    "npc_dota_hero_kunkka__en:n"                     "クンカ"
    "npc_dota_hero_lina:n"                           "Lina"
    "npc_dota_hero_lina__en:n"                       "リナ"
    "npc_dota_hero_mirana:n"                         "ミラーナ"
    "npc_dota_hero_mirana__en:n"                     "Mirana"
    "npc_dota_hero_mirana_persona1:n"                "ミラーナ（ドラゴンの血）"
    "npc_dota_hero_mirana_persona1__en:n"            "Mirana (Dragon's Blood)"
    "npc_dota_hero_slardar:n"                        "スラーダー"
    "npc_dota_hero_slardar__en:n"                    "Slardar"
    "npc_dota_hero_lion:n"                           "ライオン"
    "npc_dota_hero_lion__en:n"                       "Lion"

人間なので失敗は誰にでもあります。そこを攻めるつもりはありません。

ただ、こんな完全に初歩的なミス、1回だけでもゲームを起動してヒーロー一覧を見るだけで気づきますよね？

翻訳者はそれすらしていない証拠になります。

2. 公式翻訳なのに新パッチの日本語訳が当日に来ない

公式翻訳の一番のメリットであるゼロデイパッチがされません。

なんのためのお墨付きですか？

3. ゲームエンジンが日本語表記を完全にサポートしていない

悪いのは翻訳者だけでなくValve側にもあります。

完全にこれと同じ問題がDota2のゲームエンジンに長期間残っています。

これのせいで日本語でプレイしてもすべての漢字は中国語のものが表示されるし、一部の記号は正常に表示されません。

公式でサポートするならこれも解決してほしい。

4. コミュニティが築き上げてきた用語を完全に無視した

いくつか例を上げます。

オリジナル	公式
チャネリング	詠唱
イリュージョン	分身
基本/強化ディスペル	通常/強ディスペル

強ディスペルってなんやねん語感終わってるだろ。

他にもたくさんあります。

これらを安易に変えることは既存のプレイヤーと新規プレイヤーとの間で語彙に差が生まれ混乱の元となります。

5. どうせ翻訳するのにカタカナばっかりはどうなの？

ヒーロー名をカタカナに翻訳するのはまだ良しとしましょう。

それでもスキル名をほぼ全部カタカナにするのはどうなんでしょうか。

「エイコーンショット」ってなんだよどう考えても「どんぐりショット」のほうがいいだろ。

フードウィンクがどういうヒーローか知ってる？エイコーンの日本人の認知率知ってる？

6. カタカナばっかりはどうなの？と言ったな、あれは嘘だ。

絶対にDota2のヒーロー名アイテム名スキル名は英語のままのほうがいいと思っている。

完全にこれは自分のエゴなんですが、100%これを推しているので、公式日本語訳が追加された今でも非公式のMODの作業を続けています。

カタカナ語は横に長い

カタカナは横に長い言葉です。

英語で1番横に長いヒーローは何だと思いますか。

Keeper of the Light です。長いですね。これをカタカナにしてみましょう。

キーパー・オブ・ザ・ライト 長すぎて税金を払う必要が出てきそうです。

キーパー・オブ・ライト 公式日本語訳では節税のためにこれになりました。

カタカナ語は通じない。

Dota2には日本人口がほとんどいません。

一緒の試合に日本人がいることはごくごく僅かです。

つまり、コミュニケーションの手段として日本語が使えないことが確定しているのです。

もし、日本語でプレイしているプレイヤーがこんなチャットを受け取ったらどうなるでしょうか。

"hey cm can you buy eul?"

辛うじてcmはクリスタルメイデンのことであるとわかるかもしれませんがeulがユールの聖セプターであることには気付けないでしょう。

カタカナ語はダサい

突然ですが、日本人のあなたに聞きます。

どちらのほうがかっこよさそうに見えますか？

トレントの守護者
Treant Protector

自分は圧倒的にBです

古来より日本人は英語のままの固有名詞をデザインとして扱うことを受け入れて創作をしてきました。

たくさんの日本産のゲームが日本での発売向けにデザインとして英語を使って販売しています。

Dota2には一般的な名称が多い

たとえヒーロー名、アイテム名、スキル名であっても、Dota2には一般的な単語がそのまま

英語のほうがイイ

他のゲームでも一部を英語のまま維持するゲームも存在します。

例えばRainbow Six Siegeなど。

Dota2も同様の理由で英語のほうが適切だと思います。

とまあこんな感じで

この日本語翻訳のやる気のなさが続くようならば自分も非公式日本語訳をメンテし続けます

せめてどこが翻訳業務をしているかわかればなんとかコンタクトを取っていろいろできるのに...

それではこの変で

お暇～ S

OMORIのMODのインストール方法

Fri, 27 Feb 2026 00:00:00 GMT

必要なもの

OMORIのMODで遊ぶには必ずSteam版のOMORIが必要です。

他のSwitch版やXBox版では不可能です。

MODのダウンロード

mods.oneから必要なMODファイルをダウンロードします。

OneLoaderはMODローダーなので必ず必要です。

基本的に最新版を使うようにしてください。

OneLoaderのインストール

ダウンロードしたOneLoaderのzipファイルを開きます。

SteamからOMORIを右クリックして「プロパティ」を開き、「インストール済み」タブから「参照...」ボタンを押してOMORIフォルダを開きます。 (以降このフォルダをゲームフォルダと呼びます)

OneLoaderのzipファイルの中身をゲームフォルダに貼り付けます。

ゲームフォルダの中の別のフォルダに貼り付けてしまわないように注意してください。

「ファイルを上書きするか」の警告が出れば正しい位置に貼り付けできています。

出てこなければなにか間違えています。

OneLoader以外のMODファイルのコピー

OneLoader以外のあなたが入れたいMODファイルをゲームフォルダのwww/modsの中に入れます。

元々oneloaderフォルダが入っているはずです。

基本的には.zipファイルをそのままコピーすればOKです。

MODを外したいときはその.zipファイルをここから取り除くだけでOKです。

注意点

MODデータを遊ぶ前にかならず元のセーブデータをバックアップしてください。

セーブデータはゲームフォルダのwww/saveに保存されています。

もとの一切MODが入っていない状態に戻したいときはSteamからOMORIのプロパティを開き、「インストール済みファイル」から「ゲームファイルの整合性を確認」で元に戻すことができます。

新サイト

Fri, 27 Feb 2026 00:00:00 GMT

新しいホームページを用意した

ブログもここで管理するようにした

フレームワークはAstroでFuwariというテーマを使っている

やっぱりhtmlやデザインは苦手だ...

Godotのプラグインを作っている

Fri, 27 Feb 2026 00:00:00 GMT

その名も...

yasuna.gd

作ってるゲームでシナリオの管理にいいプラグインが見つからないので作ることにした。

今まではBlockflowを使っていたのだけれどもこれだと実現できない機能が必要になってきた。

似たようなプラグインはいくつかあったんだけど、大抵はどれもビジュアルノベルっぽいシステムを作る前提で作られていた。

今回のプラグインの要件はこれ

グラフエディタを使ってビジュアルスクリプトのようにシナリオを管理できる。
グラフエディタ上でカスタムコントロールを追加し、プレビューできるようにする。
非同期のタスクをサポートし、出力もある程度自由にできるようにする。
現在実行中のタスクを任意のタイミングでセーブ、ロードができるようにする。つまりステートフル。

特に最後の要件を満たせそうなのは1つも見つからなかった。

Half-Lifeのようなリアルタイムセーブを導入したいので必要な要件。

今はこれを書き始めて3日目だけど思ったよりいいペースでできている。

最低限の動作ができるところまでできた。

ただ、GodotにSetが無いのがつらい...

OMORI REVERIE CH4 日本語版

Fri, 27 Feb 2026 00:00:00 GMT

[!IMPORTANT] このページにはゲーム「OMORI」のネタバレが多少含まれています

REVERIEとは

REVERIEはOMORIに新たなストーリーを追加する非公式の大規模なMODです。

トゥルーエンドの引っ越しのあとに、主人公が現実世界の新しい土地と変わってしまったヘッドスペースを冒険する、といった内容になっています。

今回ヘッドスペースでは今までのお友達とは別に「パンキジ」「スイートハート」「スペースボーイ」の3人と一緒に冒険します。

ヘッドスペースは大きく姿を変え、新しいエリアも増えています。

エネミーやボス、アイテム、スキル、音楽なども新しいものが多数追加されています。

現実世界パートでは完全に新しい都会での生活を送ります。

2026年3月1日にチャプター4の日本語版を公開しました。

通しで遊べば12時間ほど遊べるボリュームとなっております。

難易度

難易度が選択できるようになっており、「かんたん」「ふつう」「むずかしい」の3種類から選べます。

「かんたん」はチャプター4で新しく追加された難易度です。

「ふつう」はオリジナルのOMORIより少し難しめな難易度となっています。

「むずかしい」でないとエネミーが使わないスキルが一部あるので、すべてのコンテンツを網羅するには「むずかしい」を遊ぶ必要があります。

最初は「ふつう」で遊ぶのをおすすめします。

ピクニックバスケットでいつでも難易度の変更が可能です。

遊ぶには

このMODで遊ぶにはSteam版のOMORIが必要です。

Switch版やXBox版など他のOMORIでは不可能です。

必要なMODは以下の3つです。

OneLoader
すべてのMODを動作させるのに必要なMODローダーです。
MinecraftでいうForgeのようなものです。
REVERIE
今回の追加コンテンツのMODです。
CJK Data Compatibility
英語版ではないOMORIで英語版向けのMODを使えるようにする互換MODです。
REVERIE日本語版は英語版を改変して作っているので必要な前提MODです。

MODのインストール方法はこちらの記事を参考にしてください。

REVERIEの世界へようこそ

「はじめる」を選んで、難易度選択画面が出れば正常に導入されています。

うまく行かない場合、DiscordのREVERIE日本語サーバーで質問してみてください。

ヒント

バニラとセーブデータは共有です。

セーブデータはwww/saveの中に入ってるので、バックアップを取ることを強くおすすめします。

MODの影響で元のセーブデータが壊れる可能性もあります。

MODのタイトルにチャプター4という文字が入っていますが、最新版の1つだけでチャプター1から4まですべてのデータが含まれています。

チャプター4のバージョンからセーブスロット追加MODが標準で含まれるようになったため、これらを導入する手間もなくなりました。

REVERIE標準で追加された便利なMODの設定がオプションに追加されているので確認するのをおすすめします。

チャプター4の導入の注意点

追記です

前回(チャプター3)時点で導入をおすすめしていたセーブスロットを追加するMODのsaveloadplusが入っていると不具合が起こることがわかりました。

チャプター4のREVERIEにはこのMODが標準で含まれているので、手動で導入しなくてもセーブスロットの追加が可能です。

チャプター4を遊ぶ前に必ずsaveloadplusMODを取り除いてください。

よくある質問

どのバージョンを使えばいいですか？
日本語のバージョンは+jpを含んでいます。
基本的に最新バージョンを入れれば問題ないはずです。
セーブデータは引き継ぎできますか？
MODのない元のOMORIとは全く別のセーブデータを作る必要があります。
REVERIEのチャプター2.5かそれ以降のバージョンのセーブデータなら新しいバージョンでもそのまま続きから始めることができます。
YouTubeやTwitchで配信してもいいですか？
全く問題ないです！
もし配信してくれるならぜひDiscordサーバーで宣伝してください。見に行きます！

最後に

REVERIEはかなりボリュームが大きく、翻訳作業だけでかなりの時間を費やしています。

自分1人だけでほとんど全ての文章を翻訳しているため、漏れやミスがあるかもしれません。

また、口調なども基本的に自分の独断で決めているため、プレイしていて

「俺のスイートハートはこんなセリフ言わない！！」

みたいな解釈違いが起こるかもしれません。

そんなときはDiscordでこっそり教えてくれると嬉しいです。

というわけで、OMORIが好きな人はREVERIEを遊んでみてね！

感想はTwitterでハッシュタグ#omori #reverieをつけて投稿してください！

アップデート

2026年03月22日に翻訳の一部を修正したバージョン4.1.3+jp.3を公開しました。

アップデートを推奨します。

Unreal Engine触ってた人がGodot Engineを使いだしていいなと思ったところ

Fri, 27 Feb 2026 00:00:00 GMT

自分は長い間趣味でUnreal Engineを触っていました。

初期の有料時代から触っており、アンリアルフェスには何回も参加したし、今は無きブルーマンのTシャツも持ってます。

ただ、Godotでインディーズゲームを作り始めてから、Unrealのここがしんどく、Godotに移行して良かったと思ったことが多数あったので、それをまとめてみたいと思います。

ただ、注意してほしいのは今回紹介するのはUnrealの悪いところではなく、お互いのゲームエンジンの個性です。

その個性が自分のやりたいことに合っていたかどうかの紹介であって、これだからUnrealは悪いという意味ではないのでそこだけ誤解しないようにしてください。

今回紹介してる内容は全部メリットもデメリットも両方あり、自分がやりたいこととGodotのメリットが重なっていたというだけの話です。

ちなみに自分はUnityはほとんど触ったことがないのでUnityの話は一切出てこないです。

1. Godotはアセットがテキストベース

Unrealでは基本的にアセットを.uassetのバイナリ形式で保存しています。

ですが、Godotではリソースの保存にテキストベースの.tresとバイナリの.resの両方が使えるようになっています。

開発プロジェクトでは.tresを基本的に使うのですが、これがGitとの相性が抜群に良いです。

コミット前に変更点が見られる、マージもしやすい、ファイルを管理するうえでは最高のメリットです。

Perforceを使えばバイナリでもできるのかもしれないけど使ったことがないのでわからない...

ただし、3DモデルであってもBase64エンコードされた頂点データなどがそのまま.tresに直書きされているので、重たいアセット/リソースが大量にあるゲームだとUnrealのほうが優れているでしょう。

2. エンジンのソースコードが読める

ここで言う読めるは閲覧できるという意味ではありません。

可読性の話です。

自分はC++は最小限のことしかわからないです。

そんな中、Unrealのコードを読もうとしてもマクロや最適化の嵐で理解するのにかなり時間がかかりました。

ですが、GodotのソースコードはUnrealと比べると、良く言えば素直、悪く言えば最適化なんて知るか、って感じでかなり読みやすいです。

昔SkeletalMeshがどういう構造でモデルデータを保持しているのか読もうとしたけど挫折した記憶があります。

あと個人的にUnrealのソースコードのifのネストは深すぎやしませんかね...

早期リターンするだけでもう少し読みやすくなるとは思うんだけど...

3. ブループリントはやっぱりしんどい...

Unrealを触りたての頃はブループリントは直感的だなと思ってました。

が、ゴリゴリBPで実装しようとするとテキストベースのコードよりもスパゲッティになりやすい。

本当に簡素なスクリプトならかなりいいだろうけどBPのみでゲームを丸々作るのはテキストベースのコードよりしんどみを感じました。

ただ、Godotのスクリプト言語であるGDScriptにも別のしんどさがあります。

そもそも型表現はあるけどかなり表現力が乏しく...

range-based-forで作った変数はVariant(いわゆるany)になるし...

for e in enemies:
    var enemy := e as Enemy # いつも再代入してる

型引数はネストできないし...

var items: Array[Item] # これはできる
var cells: Array[Array[Cell]] # これはできない

配列から要素をgetするとき型指定しないとVariantになるし...

var inventories: Array[Item]
func _use_item(slot_index: int) -> void:
    var item: Item = inventories.get(slot_index) # Item型を明示しないとVariantになる
    var item := inventories[slot_index] # 演算子なら自動で解決できるが境界外にアクセスするとエラーになる

interfaceもtraitもmixinも多重継承もないし...

# えっ？ interfaceが無いだって？
# 大丈夫、動的スクリプト言語だからNodeから直接メソッドを呼べばいいよ
# エラーが怖い？ .has_method で確認すればいいじゃん！
func get_instigator() -> Character:
    return _instigator

型周りだけで余裕で3時間は話せる。

Golangが好きな自分にとってはつらい。

型たたき券はどこへ置いたっけな...

でもUnrealでもブループリントで基本のコレクション型以外で型引数使えないしな...

でもGDScriptにはそもそもSetがないしな...

(ちょっと待ってGodotのほうが劣勢じゃね...？)

やっぱり独自のスクリプト言語の実装なんてやめたほうがいいのでは...？

4. ちょっと変なことしようとするとUnrealはつらい

昔UnrealでSource EngineのマップインポーターをBPで作ろうとしてたことがあります。

ホントにホントの最小限の動作までこぎつけましたが、山盛りペペロンチーノが出来上がりました。

Source Engine内のBSPブラシをUnreal EngineのBSPブラシに変換するBPのコードはまさに変態的でした。

今のUnrealならGeometry Scriptでもう少し簡単に組めると思うけど、それでも同じ機能をGodotで実装しようと思うArrayMeshを使ってよりシンプルにより素直に書くことができる気がします。

最初ArrayMeshって言葉聞いたときに、なんで配列が関係してんだよ！

って思ったんですが本当に頂点データの配列って意味で拍子抜けした記憶があります。

話がそれましたが、バージョンアップで改善はされていると思うけど、少しそれたことをやろうとすると、Unrealだと結構しんどい印象があります。

5. やっぱりエディタが重い！

うん、いやUnrealのあの多機能さを知ってると正直「ここまで滑らかに動くのすげー！」とはなるんですけど...

そこまで機能を網羅できるほど優れたエンジニアではないのですよ...

やべっ、今日が終わる。

それではこの辺で、お暇～