2026年9月2日、SteamDBがNexus Modsと同じChosen傘下に入ったことが発表された。
価格履歴や同時接続数を見るためにSteamDBを使っているだけなら、当面の変化はほとんどない。SteamDBは独立したサイト、ブランド、コミュニティとして残り、現在無料の機能も無料のまま維持する方針だ。一般的なディスプレイ広告やプログラマティック広告も導入せず、収益化はアフィリエイトや提携など別の方法を検討するとしている。
ただ、今回のニュースを運営母体の変更だけで読むともったいない。
SteamDBには、価格やプレイヤー数とは別に、ゲームのBuild、Depot、Manifest、ファイル構成と、その変更履歴が10年以上蓄積されている。Nexus Modsが持っているのは、MOD本体やバージョン、Collection、MOD ManagerといったMOD側の情報だ。
ゲーム本体の履歴とMOD側の情報を結び付けられれば、「どのゲームバージョンで、どのMODが動くのか」という、今まで作者とユーザーが手で管理してきた情報をツール側で扱えるようになる。
ここが今回いちばん面白いところだと思う。
Skyrimの「このバージョンならこちら」は今も手作業が多い
SkyrimのMODページでは、ゲームのバージョンによってダウンロードするファイルが分かれていることが珍しくない。
SteamDBのFAQでも、Version pinningの例として「このCollectionにはSkyrim 1.6.1170が必要」というケースが挙げられている。実際のMOD環境でも、対応するゲームバージョンが説明文、ファイル名、コメント、フォーラムなどに書かれ、ユーザーが自分の環境と見比べて選ぶ形が多い。
Skyrim 1.6.1170
-> MOD A のファイル1
-> MOD B 2.4
-> SKSE対応版
別のゲームバージョン
-> MOD A の別ファイル
-> MOD B の別バージョン作者はゲーム更新のたびに動作を確認し、必要なら対応ファイルを追加する。ユーザー側は自分のゲームバージョンを調べ、説明を読んで正しいファイルを選ぶ。どこかで取り違えると、「入れたけれど動かない」という話になる。
MODなので完全自動化が難しい部分は残るとしても、バージョンの対応関係そのものは、かなり人間の判断に寄っている。
SteamDBには「そのゲームがどう変わってきたか」が残っている
SteamDBはSteam上のゲームを、単純な1つの製品としてだけ見ているわけではない。公式FAQでは、ゲームの状態を次の単位で追跡していると説明している。
Game
-> Build
-> Depot
-> Manifest
-> File listゲームが更新されればBuildが変わり、どのDepotやManifest、ファイルが変化したのかを追える。
Nexus Mods側も以前からSteamゲームのデータ収集を始めていたものの、ゲーム更新後に古いManifestなどを取得しにくくなる問題があった。SteamDBには、その過去分が長期間残っている。
たとえばMOD作者が「このMODはGame Build Xで確認済み」という情報を持ち、MOD ManagerがユーザーのGame Buildを把握できれば、ダウンロード前や導入前に照合できる。
ユーザーのゲーム
Build: X
|
v
MODの対応情報
Build: X
|
v
対応確認済みゲーム側にBuild Yが配信されたときも、現在のMOD構成がBuild X向けだと分かっていれば、更新前に警告を出せる。Nexus Modsは、SteamDBのデータを使ったVersion pinningや、ゲーム更新によるMOD環境の破損を防ぐ用途を実際に挙げている。
今まで説明文で管理していた情報の一部が、初めてゲーム側の履歴と直接つながるわけだ。
MOD環境にもlockfileのような発想を持ち込める
ソフトウェア開発では、依存パッケージのバージョンを固定して同じ環境を再現するために、package-lock.json や Cargo.lock、コンテナイメージなどを使う。
MOD環境も、実はかなり似た問題を抱えている。
Collectionに100個のMODが登録されていても、MODの一覧だけでは「そのとき動いていた環境」を完全には再現できない。ゲーム本体のBuild、Mod Loader、依存MOD、各MODのバージョンまで合っている必要がある。
Game
Steam Build: X
Mod Loader
Version: A
Mods
Mod A: 1.4.2
Mod B: 3.1.0
Mod C: 2.8.4SteamDBとNexus Modsのデータが十分に結び付けば、Collectionに「どのMODを入れるか」だけでなく、「どのゲームBuildを前提にした構成なのか」まで持たせやすくなる。
package-lock.json と同じものになるわけではない。MODにはロード順、設定ファイル、競合、外部Loader、ユーザーによる手動変更などがあり、ゲーム本体のBuildだけを固定しても同じ環境にはならない。
それでも、ゲーム本体の正確なバージョンが共通データとして入る意味は大きい。MOD側のバージョンだけを固定するより、再現できる範囲が一段広がる。
ゲームが更新されてから壊れるのではなく、更新前に分かる
MOD環境では、昨日まで正常だった構成がゲーム本体の自動更新で突然動かなくなることがある。ゲーム内部の関数をHookするネイティブプラグインや、特定の実行ファイルを前提とするMODは特に影響を受けやすい。
Game BuildとMOD側の対応情報が結び付いていれば、MOD Managerは少なくとも「ゲームが変わった」という事実を正確に把握できる。
現在
Game Build: X
Mod A: Build Xで確認済み
Mod B: Build Xで確認済み
SteamにBuild Yが公開
Mod A: Build Y 未確認
Mod B: Build Y 対応済みこの場合、互換性そのものをSteamDBが判定する必要はない。「Build YではMod Aが未確認」というところまで分かれば、更新前の警告には使える。
壊れてからゲーム更新に気付き、どのMODが原因なのか一つずつ調べるよりはずっといい。
不具合報告の切り分けにも使える
MODの不具合報告で厄介なのは、「このMODを入れたら動かなくなった」と言われても、原因がMOD本体とは限らないことだ。
ゲームファイルが欠けている、以前入れたファイルが残っている、別のMODが上書きしている、といった状態でも同じ報告になる。
SteamDBのFAQでは、保持しているファイル情報を使って、正しくインストールされたゲームとユーザー環境を比較する可能性にも触れている。
Clean Game
A.dll
B.dll
data.bin
User Environment
A.dll
B.dll <- 変更あり
data.bin
ModLoader.dllこうした差分が取れれば、「ゲーム更新で変わったのか」「インストールが壊れているのか」「MODが変更したのか」という切り分けに使える。
MOD作者にとっては、バグ修正そのものより、その前段にある環境確認の往復を減らせる可能性がある。
APIが出ればMOD開発のCIまで考えられる
SteamDBは今回のFAQで、開発者やパブリッシャー向けのツールを強化し、その延長として将来的にAPIを提供する可能性が高いとしている。
まだAPIの仕様、公開範囲、料金、利用条件は出ていない。ここからは、そのAPIでゲームBuildの更新情報を取得できるようになった場合の話になる。
MOD開発では、ゲーム更新を検知した時点でCIを起動する仕組みも考えられる。
新しいGame Buildを検出
|
v
CIを起動
|
v
MODをビルド
|
v
互換性テスト
|
+----+----+
| |
success failure
|
v
Issueを作成ゲーム内部へ強く依存するMODなら、自動テストまで行かなくても、新しいBuildを検知して作者へ通知するだけで役に立つ。今までSteamDBを手で確認していた作業を、開発フローの入口にできるからだ。
Nexus ModsやSteamDBがこのCI機能を発表したわけではないので、現時点では将来像にすぎない。ただ、SteamDBの履歴がAPIとして扱えるようになるなら、MOD開発者が自分のツールを作れる余地はかなり広がる。
Webエンジニアへの直接的な変化は小さいが、データ基盤としては面白い
一般的なWeb開発に、今回の買収が直接影響するわけではない。SteamDB APIもまだ公開されていないので、Webエンジニアが明日から使える新しい機能が増えたわけでもない。
ただし、SteamDBとNexus Modsが持っているデータをどう接続するかは、Webやバックエンド、データ基盤の題材として面白い。
SteamDBには10年以上のゲーム変更履歴があり、Nexus ModsにはゲームごとのMOD、ファイル、バージョン、Collectionがある。ゲーム更新は今後も続くので、一度関連付けて終わりではなく、新しいBuildが出るたびに追従する必要がある。
Steamの更新
|
v
SteamDBの履歴
|
v
ゲームBuildを識別
|
v
MODメタデータと照合
|
v
Nexus Mods / MOD ManagerSteam関連サービスを作る開発者にとっては、将来SteamDB APIが一般向けにも使える形で公開されるかどうかが一つの分岐点になる。
13年続いた個人発サービスをどう残すか
今回の発表には、MODとは別にもう一つエンジニアとして気になる話がある。
SteamDBは2013年にxPawとMarlaminが始めたプロジェクトで、その後Marlaminが離れ、長いあいだxPawを中心に維持されてきた。公式FAQでは、この状態をかなり率直に「bus factor of one」と表現している。
利用者が増え、SteamDBが多くの人に頼られるサービスになっても、運営が一人の時間と負担に大きく依存している状態は変わらない。サービスそのものが成功するほど、継続性のほうが問題になっていく。
Chosen傘下へ移った後は、SteamDBをクロスファンクショナルなチームで開発し、インフラ、セキュリティ、スケーラビリティへ投資する方針が示されている。ゲームファイルやDepotを追跡するために必要なSteamキーも、寄付だけに頼らず運営側で購入してカバレッジを広げるという。
個人の好奇心から始まったサービスが13年続き、今度は「どう残すか」が技術課題になる。個人開発の先にある話として、こちらもかなり興味深い。
Game Buildだけでは解決しない問題も残る
ゲーム本体のBuildが分かるようになっても、それだけでMOD互換性を完全に判定できるわけではない。
MOD環境には、Mod Loaderのバージョン、依存MOD、ロード順、設定ファイル、ファイル競合、ユーザーによる手動変更などがある。Steam以外のストアで配布されるゲームもあり、ゲームやパブリッシャーごとにMODへの方針も違う。
SteamDBとNexus Modsも、今後引き続き別サービスとして運営される。SteamDBがそのままMOD配布サイトになるわけではない。
Nexus Mods側も、SteamDBのデータをMOD ManagerやMODメタデータへ接続するには多くの作業が残っており、まだ存在しない機能を約束したくないと説明している。
今の段階で手に入ったのは完成した自動互換性判定ではなく、その土台になり得るゲーム側の長期履歴だ。
SteamDBの履歴が「調べるための情報」だけではなくなる
SteamDBはこれまで、価格履歴や同時接続数だけでなく、更新履歴、Depot、Manifestを調べる場所として使われてきた。そのデータを人間が見るだけなら、SteamDBは非常に詳しい情報サイトのままだ。
Nexus Modsと組み合わさることで、同じデータをMOD Managerがゲーム環境を判断するために使える可能性が出てきた。
Skyrimで「1.6.1170ならこのファイル」と書かれている情報を、いつかMOD Manager自身が判断できるかもしれない。CollectionにはMOD一覧だけでなく、前提となるGame Buildまで残せるかもしれない。APIが使えるようになれば、ゲーム更新を起点にMODのCIを動かすことまで考えられる。
まだ実装されていないものは多い。それでも、SteamDBが13年間積み上げてきたゲーム側の履歴と、Nexus Modsが持つMOD側の情報は、用途がかなりきれいにつながっている。
SteamDBが組織的な開発体制を得るだけでも運営上は大きな変化だが、その履歴がMOD環境の再現性や開発ワークフローに使われ始めたら、今回の移行は単なる運営会社の変更では終わらない。
参考
https://steamdb.info/blog/steamdb-nexus-mods/
Frequently Asked Questions about SteamDB Joining Nexus Mods
Frequently Asked Questions about SteamDB Joining Nexus Mods.
https://steamdb.info/faq/?guildid=215154001799413770
https://www.nexusmods.com/news/15597
