Total War: SHOGUN 2 Moddingツール：PackファイルとDBエディター

適切なShogun 2 moddingツールを選ぶことは、プロジェクトが完成するか頓挫するかを決める最大の要因です。Total War: SHOGUN 2のmoddingシーンは、少数のアンパッカー、テーブルエディター、そして詳細にドキュメント化されたコミュニティワークフローによって成り立っているからです。刀侍の単一ステータスのリバランス、Fall of the Samuraiのオーバーホール向けユニットロスターの入れ替え、あるいはフルのトータルコンバージョンの構築など、目標が何であれ、同じ一握りのユーティリティが何度も登場します。このガイドでは、各ツールが実際に何をするのか、ビルドパイプラインのどこに位置するのか、そしてComplete Editionのビルドと2011年のレガシービルドが互いに噛み合わなくなるのを防ぐ方法を解説します。moddingレイヤーでも同じ重複が見られます。Shogun 2 Rise Of The Samurai Modsでは、同じキャンペーンフレームワークが実際にはClassic版とComplete Editionのインストールの両方を支え続けている様子を確認できます。

Moddingスタックの全体像

個々のツールを開く前に、スタック全体をパイプラインとして把握しておくと役立ちます。すべてのShogun 2 modは少なくとも3つのレイヤーに触れます。ゲームのデータを保持する圧縮されたpackファイル、ユニットのステータス、建物チェーン、キャンペーンスクリプトを駆動するデータベーステーブル、そしてランチャーとWorkshopが完成品を公開するために使うフロントエンドファイルです。各レイヤーにはツールが存在し、初心者が直面する摩擦のほとんどは、データベースで編集すべきものにpackファイルツールを使おうとすること（またはその逆）から生じます。

最初のクリーンなプロジェクトでは、データベースレイヤーとpackファイルレイヤーのみに触れます。スクリプティングとローカライゼーションのレイヤーは、modderが新しいメカニクスの追加、キャンペーンイベントの分岐、または再構築されたComplete Editionクライアント向けにカスタムユニット名を日本語や中国語に翻訳する必要が生じた時点で後から関わってきます。

スタックがこのような構成になっている理由

Creative AssemblyのエンジンファミリーはEmpire、Napoleon、そして2つのTotal War: SHOGUN 2キャンペーン間でツールを共有しています。そのため、同じpackファイル形式がRise of the Samurai、基本の1530年戦国キャンペーン、そしてFall of the Samuraiの1864年戊辰戦争の設定をすべてカバーしています。DBテーブルはユニットカード、建物効果、勢力ボーナスについて共通のスキーマを共有しているため、基本ゲームでのShimazu向けリバランスは、近代化されたユニットロスターへのわずかな調整だけで、Fall of the Samuraiのサブmodに移植できるのが通常です。この共有された基盤があるからこそ、ベテランmodderは大規模なツールセットではなく1〜2のコアツールを推奨する傾向があります。あなたの意図とバイナリの間の翻訳が少ないほど、QAで問題になるエッジケースも少なくなるのです。

Packファイル編集：すべてのmodの出発点

Packファイル編集は、あらゆるTotal War: SHOGUN 2 modの基盤レイヤーです。ゲームはほぼすべて — テクスチャ、モデル、UIレイアウト、オーディオキュー、スクリプト化された戦闘 — をインストールディレクトリのdataフォルダ以下にある圧縮された.packアーカイブ内に格納しています。packをアンパックし、ファイルを差し替え、きれいに再パックできるmodderなら、データベースの行に一切触れることなく、テクスチャオーバーホール、ユニットのリスキン、サウンドの置き換えを公開できます。

このレイヤーを支配する2つのツールは、Pack File Manager（TWC moddingコミュニティによって長年メンテナンスされているコミュニティユーティリティで、しばしばPFMと略されます）と、Rustで書かれたより新しいクロスプラットフォームの後継である**Rusted PackFile Manager（RPFM）**です。どちらも.packアーカイブを直接開いて表示・編集でき、ゲームの内部フォルダ構成も理解しているため、エディター内の正しい仮想フォルダにドラッグされたファイルは、アーカイブ内の正しい場所に配置されます。

2026年の新規プロジェクトには、統合されたテーブルビューを備え、Creative Assemblyがデータを調整するたびにスキーマの更新を追跡してくれるRPFMがより良い出発点です。既存の2011年時代のビルドと並行して公開しなければならないmodには、Pack File Managerが素の互換性で勝ることがあります。長寿命のmod packの一部はPFM特有のクセを前提に作られており、警告なしではRPFMで往復処理できないことがあるからです。ほとんどのmodderは両方をインストールしたままにし、問題のpackをきれいに開ける方に応じて切り替えています。

クリーンなPack編集ワークフロー

典型的な最初のpack編集は次のような流れです。変更したいファイルを含むpackを特定し（ユニットテクスチャなら、ほぼ必ずroman_imperial.packかその勢力固有の類似パックです）、RPFMで開き、置き換えファイルを対応する仮想パスにドラッグし、元のpackが手つかずのまま残るよう新しい名前でコピーを保存し、そのリネームしたpackを新規modディレクトリのdataフォルダに入れ、Workshopアップローダーから結果を公開します。

ここで多くの苦労を避けるための2つのルールがあります。第一に、packをその場で編集しないこと。必ずコピーし、リネームし、コピーを編集してください。単一の破損したpackがランチャーを固め、検証を強制されることがあります。第二に、元のファイル名構造を維持すること。エンジンは多くのアセットを正確なパスで解決するため、ui/skill_icons/に置かれたテクスチャは、UI/Skill_Icons/に置かれていると読み込まれません。packファイルの参照はほとんどのプラットフォームで大文字小文字を区別するからです。

DBエディター：ステータスとシステムが存在する場所

Packファイル編集が基盤なら、データベースエディターは構造的な骨組みです。プレイヤーが目にするすべての数値 — 槍足軽の近接攻撃力、鉄砲足軽のコスト、城の領国が防御に与えるボーナス — はDBテーブルに存在し、それらの数値を変更することが多くのmodで言う「本物の modding」という作業です。このレイヤーのコミュニティ標準は年々変化してきましたが、現在のベストプラクティスは、カジュアルな編集にはRPFMの内蔵テーブルビューを、大規模なスキーマ作業にはTWC DBTable Editor（長年のメンテナにちなんでAlthaeaエディターと呼ばれることもあります）を使うことです。

単一ユニットへのDBテーブル編集は通常、次のような流れになります。RPFM内でunits_tables DBを開き、キー（例：yari_ashigaru）でユニットをフィルタリングし、melee_attack、melee_defence、またはcostの列を変更して保存し、再パックします。この変更は、そのユニットが参照されるすべての場所に波及します。Fall of the Samuraiのサブmodも含まれます。両方のキャンペーンがほとんどのコアユニットについて基盤のスキーマを共有しているからです。

知っておくべき重要なテーブル

よくある最初のプロジェクトは、単一のあまり使われないユニットのリバランスです。例えば、薙刀侍にわずかな近接防御バフを与えて、Takedaの編成で中間ティアの実用的な選択肢にするといったものです。この変更は完全にunits_tables内で行われ、5分で完了し、プレイヤーが次のキャンペーンターンで実感できる結果を生み出します。

初心者向けDBエディターワークフロー

DBエディターを開いたことがない人にとって、最も抵抗の少ない道筋は次のとおりです。RPFMをインストールし、スキーマを読み取れるようShogun 2のインストールディレクトリを指定し、units_tablesを開き、変更したいユニットを見つけ、数値を1つ編集し、保存し、ゲームを起動し、結果を確認します。この単一のループだけで、packの再パッケージング、スキーマ移行、ロード順管理を一度に学ぶ負担なしに、ワークフローを習得できます。

そのループに慣れたら、次のステップは同じパッチ内で関連テーブルを変更することです。units_tablesでユニットの徴兵コストを引き上げ、building_chainsで建物要件を調整し、リバランスが特定のテックを通じて展開されることを意図するならtechnologiesで小さなボーナスを与えます。このパターンは、modがバージョン管理とチェンジログで追跡された調整の小さなエコシステムになるまで繰り返されます。そうすることで、他のmodとの競合を完全なアンインストールなしで診断できます。

Modをエンドツーエンドで構築する：アイデアからWorkshopまで

最初のフルmod — 小さなユニットパックか焦点を絞ったリバランス — は、ワークフローを学ぶのに適したスコープです。スクリプティングやローカライゼーションを引き込まずにすべてのレイヤーを動かせるからです。初心者のmodプロジェクトに対する現実的なエンドツーエンドのパイプラインは次のとおりです。1ページの設計ドキュメントでスコープを定義し、data/以下にmodフォルダをセットアップし、Pack File ManagerとRPFMの両方をインストールし、変更すべきテーブルとpackを特定し、小さなコミットで変更を行い、再パックし、ゲーム内でテストし、反復し、最後にSteam Workshopアップローダーを通じて公開します。

適切なスコープの選択

スコープは、最初のプロジェクトが週末で完成するか3ヶ月目に死ぬかを決める変数です。単一のユニット、単一の建物、単一のテクノロジーに触れるmodは現実的な最初のプロジェクトです。その3つすべてに加えてカスタムUIとキャンペーンイベントに触れるmodは頓挫しがちです。レイヤーが1つ増えるごとにQAの負担が掛け算で増えるからです。コミュニティの経験もこれを裏付けています。Workshop上の長く生き残っているShogun 2 modのほとんどは、スコープを絞ったバランスオーバーホールか、5人以上のチームが作った大規模なトータルコンバージョンのどちらかであり、その中間で成功したプロジェクトは驚くほど少ないのです。

有用な経験則は、そのmodを1つの文で説明できるかを問うことです。「薙刀侍の近接防御を5上げて徴兵コストを50石下げる」は素晴らしい最初のプロジェクトです。「歴史的に正確な兵力比で戦国時代全体をリバランスする」はチームを必要とする5年がかりの研究プロジェクトです。Workshopは前者に報酬を与え、後者を埋もれさせます。プレイヤーは焦点を絞ったmodを1回のキャンペーンで検証でき、曖昧さなく登録または登録解除できるからです。

バージョニング、ロード順、Mod Manager

modが単一ファイルを超えると、バージョニングが主要なエンジニアリング問題になります。Steam Workshopは配布を処理しますが、セマンティックバージョニングを強制せず、組み込みの依存関係リゾルバもありません。そのため、他のmodのフレームワークに依存するmodは、その依存関係を説明文で宣言し、プレイヤーが読んでくれることを願うしかありません。ロード順は同じテーブルに触れるmodにとって重要です。最後にロードされたpackが通常優先され、壊れたmodがサブスクライバーに配信されると、登録解除するまでゲームが無効化されることがあります。

実用的なロード順管理には、ランチャーからアクセスできるゲーム内Mod Managerが適切なツールです。最近のmod manager有効化ウォークスルーでは、一時的にこのオプションが隠れた2023年5月パッチの変更を解説しています。基本ルールは、フレームワークmodを最初にロードし、次にコンテンツmod、そしてビジュアルオーバーライドの順にし、同じDBテーブルを編集する2つのmodをテストなしで同じロード位置に置かないことです。

2026年のShogun 2 Moddingコミュニティ

コミュニティは、ツールとデータと並ぶスタックの第3の柱です。質問をしたり、スキーマの発見を共有したり、互換性テストを調整したりする場所がなければ、どんなに道具の整ったmodderでも、Googleで検索できない最初のエラーで立ち往生します。幸いなことに、Shogun 2 moddingコミュニティは2026年に入っても活発であり続けており、最近のComplete Editionの再構築によって、2011年から同じpackファイルに取り組んできたベテランと並んで最初のmodを公開する新たな貢献者の波がもたらされています。

コミュニティが実際に集まる場所

初心者にとって最も重要なリソースは、TWC（Total War Center）フォーラムのピン留めされたmoddingガイドです。どのツールも警告してくれないスキーマのクセをカバーしているからです。例えば、units_tablesに新しいエントリを追加してもunit_stats_landに対応する行がないと、そのユニットが最初に徴兵された時点でハードクラッシュが発生すること、またFall of the Samuraiキャンペーンには別途編集が必要な独自のunits_tablesオーバーライドが存在することが挙げられます。

Complete Edition再構築に関する注記

Complete Editionは、Total War: SHOGUN 2 Complete Editionのストアページによると、再構築されたライティング、4K UIスケーリング、新しい日本語・中国語ボイスアクティングとともに、Shogun 2クライアントを最新のハードウェア向けに再構築しました。この再構築はファイルレイアウトに影響を与えたため、少数のレガシーmod — 特にUIスケーリングテーブルを編集したものや特定のフォントファイルに依存していたもの — が2026年のアップデート後にロードされなくなりました。2011年のSteam Workshopカタログは今もトータルコンバージョン、リアリズムオーバーホール、ブラッドmod、ユニットパックの長いバックカタログをホストしており、Complete EditionのMod.ioブラウザがその上にゲーム内レイヤーを追加しているため、ほとんどのmodはいずれかのルートでアクセス可能です。

modderにとっての実際的な意味は、新規プロジェクトは公開前にレガシーの2011ビルドとComplete Editionクライアントの両方でテストすべきだということです。片方では動作しもう片方では壊れるmodは、潜在的なサブスクライバーの半分を失うことになります。特にFall of the Samuraiのサブmodには明示的な互換性チェックが必要です。戊辰戦争キャンペーンは新しい領国（北海道、種子島、対馬、五島）を追加し、ターン構造を1年24ターン、1季節6ターンに変更したため、長期キャンペーンにおける軍隊の移動方法や消耗の蓄積方法が変わっているからです。

よくある質問

Shogun 2 moddingを始めるための最小限のツールセットは何ですか？

初心者はRusted PackFile Managerとテキストエディターだけで始められます。RPFMがpackファイル編集とDBテーブル表示の両方を1つのアプリケーションで処理するからです。配布用にSteam Workshopアップローダーを追加し、pack外のテキスト編集用にNotepad++やVS Codeを加えれば、開く・編集・保存・テストという基本ループが、有料ソフトに一切費用をかけずにカバーされます。

Shogun 2 modは2011ビルドとComplete Editionの両方で動作しますか？

ほとんどのmodは動作しますが、Complete Editionの再構築はファイルレイアウトを変更し新しいUIスケーリングを追加したため、フォントファイル、特定のUIテーブル、4Kアセットに触れたmodはロードに失敗することがあります。両方を対象とするmodは、公開前に各クライアントでテストし、どのビルドがサポートされているかをWorkshopの説明に明記すべきです。

Shogun 2のDBスキーマのドキュメントはどこで見つけられますか？

TWC moddingフォーラムが最も完全なスキーマドキュメントをホストしており、各テーブルの目的、units_tablesとunit_stats_landの関係、Fall of the Samurai固有のオーバーライドをカバーするピン留めスレッドがあります。RPFM内のスキーマは2番目に優れたリファレンスです。ライブのゲームファイルからオートコンプリートし、Creative Assemblyがパッチを当てても最新の状態を保つからです。

Fall of the Samuraiを基本ゲームとは別にmodすることは可能ですか？

はい、Fall of the Samuraiは独自のキャンペーンマップ、近代化されたバリアントを含む独自のユニットロスター、独自のテックツリーを使用しますが、基本の1530年戦国キャンペーンと基盤のpackファイル形式およびほとんどのDBスキーマを共有しています。Fall of the Samuraiを対象とするmodは、そのキャンペーンがアクティブな時にのみロードする必要があり、Mod Managerによってプレイヤーはキャンペーンでフィルタリングして競合を回避できます。

Creative Assemblyのパッチ後にShogun 2 modが壊れる原因は何ですか？

パッチ後の破損のほとんどはスキーマ変更によるものです。Creative Assemblyがunits_tablesやbuilding_chainsの列を追加またはリネームすると、古い列を参照していたmodがロード時にクラッシュします。対策としては、TWC moddingアナウンスを購読してメジャーパッチから1週間以内に互換性のあるアップデートがないか確認するか、RPFMで安定したスキーマに対してmodを作成し、そのスキーマをmodの説明に明記して、サブスクライバーがどのビルドに固定されているかを把握できるようにすることです。