UNREAL FEST 2015レポート「鉄拳7」はなぜ「Unreal Engine 4」を選択したのか

Epic Games Japanの河崎代表をいじるジョークなどを交えつつ，開講の挨拶を述べる「鉄拳開発チームの顔」的存在のチーフプロデューサー兼ゲームディレクターの原田勝弘氏

　2015年10月18日に神奈川県・パシフィコ横浜で開催されたUNREAL FEST 2015で，バンダイナムコエンターテインメントは，格闘ゲームの名作シリーズ「鉄拳7」関連や，最新VRコンテンツの「サマーレッスン」に関連したセッションを行い，大きな存在感を示していた。
　まずは，「鉄拳7」がなぜ「Unreal Engine 4」（以下，UE4）を採用したのかを解説したセッション「鉄拳にアンリアルエンジンを導入した背景」をレポートしてみたい。

自社ゲームエンジンの「NUライブラリ」ではなく

「Unreal Engine 4」を採用した経緯

セッションタイトルは，そのものズバリ「鉄拳にアンリアルエンジンを導入した背景」だ

　2014年12月で20周年を迎えた鉄拳シリーズ。1994年にアーケードゲームとしてリリースされて以来，さまざまな家庭用ゲーム機向けにリリースされてきた同作は，シリーズ累計4400万本の売り上げを記録するほどの定番対戦格闘ゲームの一つとなっている。フルCG映画や実写映画にもなり，スマホ向けアプリ，パチスロ向けにもキャラクターIPを展開しており，名実共にバンダイナムコの看板ブランドと言ってよいだろう。

　講演ではシリーズ最新作の「鉄拳7」が開発に至るまでの話が鉄拳プロジェクトの米盛祐一氏から語られた。

バンダイナムコスタジオ，鉄拳プロジェクト，米盛祐一氏

　2007年12月にリリースされた「鉄拳6」はPlayStation 3アーキテクチャベースのアーケード基板上で動作していた。2011年9月にリリースされた「鉄拳タッグトーナメント2」も同様だ。
　「鉄拳タッグトーナメント2」は，2対2のタッグバトルシステムを採用していたため，瞬間的には2対2，計4体の主役キャラクターが画面内で暴れ回ることになる。それゆえ，PS3基板では描画負荷に耐えきれない状況もあったという。これに対処するため，動的に描画解像度を変化させる「可変解像度描画システム」を実装している。
　余談にはなるが，この「可変解像度描画システム」はバンダイナムコのお家芸ともいえ，例えばバンダイナムコが開発を担当した「大乱闘スマッシュブラザーズ for Wii U」でも同様のテクニックが採用されていた。

　さて，直近，2タイトルの「鉄拳」シリーズをPS3基板で動作させてきたわけだが，最新作「鉄拳7」の開発のタイミングでは，ハイエンドPCアーキテクチャを採用したアーケードシステム基板「ES3」を採用する方針が濃厚であったために，当然，このシステム性能に見合うグラフィックス表現の向上が求められることとなった。

「鉄拳7」は，新ハードウェア上で動作することが想定されたため，グラフィックスの進化に対して多大な期待をされることとなった

　バンダイナムコには，自社製ゲームエンジンとして「NUライブラリ」が存在する。これは歴史を持つ実績の高いゲームエンジンである。サイバーコネクトツーによって開発された「NARUTO −ナルト− ナルティメットストーム」や「ジョジョの奇妙な冒険」などのアニメキャラクターゲームなども，NUライブラリベースで開発されているのは知る人も多いことだろう。裏を返せば，バンダイナムコの関連開発会社にも提供しているくらい信頼度も高いということでもある。
　当然，流れとしては「鉄拳7」も，これまでどおりNUライブラリベースでの開発となる可能性もあったのだが，あらかじめ決まっていた「鉄拳7」のリリース予定日程と，NUライブラリの新世代版の完成スケジュールが噛み合わないことが発覚した。「鉄拳7」のリリース予定はずらせない……と判断して，「鉄拳7」に関してはひとまず，社外ゲームエンジンの採用検討を始めたのだという。

社外エンジンの採用検討はある種，苦肉の策だった

UE4採用への期待と不安。最後の決め手は日本でのサポート力の高さ

　講演では，具体名こそ明かされなかったものの，採用に際しては国内外で複数のゲームエンジンを検討したようである。その結果として，鉄拳7が「ハイエンド指向のグラフィックスを求めていた」ことと，Epic Games Japanの日本語・日本時間でのサポート体制に業界内での評価が高まっていたことなどから，UEを採用する方針を採択したという。
　続いて決定しなければならなかったのは「UE3かUE4か」という「究極の選択」だったようだ。
　「最新のUE4を選ぶべきなのは当たり前なのでは？」と思う読者もいると思うので補足解説をしておこう。
　UE採用検討が始まった2013年〜2014年当時，UE4はまだ発表されたばかりで，採用実績や動作安定性での訴求力が弱かった。一方，UE3は，約10年にわたっての膨大な採用事例と，数多くのEpic Games社外プロジェクトで揉まれてきた「鍛錬度の高さ」もあり，「エンジンの安定性」を重視するならばUE3という選択肢もなくはなかったのだ。余談にはなるが，同じ格闘ゲームの「ギルティギアXrd-SIGN」でUE3採用を決定したアークシステムワークスは，エンジンの安定性面を大きく評価してUE3を採択したとしている（関連記事）。

UE3ではなくUE4を選択したのは「リスクを冒してでも新世代のグラフィックスを手に入れたかった」という理由から

　検討の結果，鉄拳7開発チームとしては，多少のリスクを冒してでも，新世代グラフィックス表現を重視したために，UE4を採択したのだという。
　とくに採用の決め手となったのは，Epic Gamesが自社開発したUE4の2作のリアルタイム技術デモ「Elenmental」（2013年）と「Infiltrator」（2014年）だったと米盛氏は振り返っている。
　実際に，UE4を検証した結果，物理ベースレンダリングによるグラフィックス表現は期待通りの品質で，キャラクターのみならず背景グラフィックスのリアリティもかなり底上げが期待できそうだということを確信し，さらに，鉄拳シリーズでは，お馴染みの「派手なエフェクト表現」もGPUパーティクルシステムなどの活用で，格段のレベルアップができそうだという見通しも立ったとしている。

UE4向けの二つのリアルタイム技術デモは鉄拳7開発チームの心を捉えた

　また，業界内でUE3およびUE4の採用実績は増加傾向にあるため，「業界スタンダードになりえるゲームエンジンの活用に挑戦することは，成功しても失敗してもバンダイナムコグループにとってよい体験になるはず」という，かなり前向きな分析もUE4採用の後押しになったと米盛氏は振り返っていた。
　また，UE4は複数の新世代ゲームプラットフォーム（PS4，Xbox OneやDirectX 11世代以降のPCなど）に対応した汎用ゲームエンジンであるため，アーケード版からの移植展開もやりやすいという部分も，移植コストの面で優位に働くかもしれないという見積もりもあったようだ。

鉄拳7の開発にUE4が使えるかどうかの検証を開始

　とはいえ，懸念事項がなかったわけではない。
　その一つは，UE4は，出たばかりのゲームエンジンであり，アップデート頻度が高めなこと。そのアップデートのたびに「ほかのミドルウェアとの相性が出たりしないか」「すでに制作したゲーム関連データへの影響が出ないか」といった不安があったという。

アップデート頻度の高いUE4。アップデートのタイミングごとに開発に支障が出ないかどうか不安であったとのこと

　そして，万が一，鉄拳7開発チーム側で解決し得ない不具合が出たときに，Epic Gamesからどの程度のサポートが得られるのかも不安だったという。
　最近のEpic Games Japanは手厚いサポートを行っており，いまやそのサポート力が，業界内でも高い評価を得ていることを知り，「なにかあったときには頼れそうだ」という手応えを得たとしている。

Epic Games Japanのサポート力がUE3時代と比べて格段によくなっているため，大丈夫だろうと判断。UE4の採用を決定した

価格交渉は原田氏が担当。高い政治能力を活かしての価格交渉は双方納得の末，折り合いはついたようである（笑）

鉄拳7開発プロジェクトはどう進んでいったのか

バンダイナムコスタジオ，鉄拳プロジェクト，ビジュアル・アーティスト，木村憲司氏

　鉄拳7開発の開発体制やタイムラインについては，ビジュアル・アーティストの木村憲司氏が言及した。

　開発プロジェクトが立ち上がったのは2013年9月頃で，2013年の11月にはUE4の検証を開始したとのこと。
　2014年の2月には筐体上で実動できる試作α版を動かすことに成功したという。その後，本格的なコンテンツ制作に取りかかり，2014年10月にはロケテストを実施している。そして，2015年3月には正式リリースが行われた。実質的な開発期間は約1年。NUライブラリの新世代対応を待って開発していたら，鉄拳7の開発規模のプロジェクトを1年で終わることは難しかっただろうと米盛氏や木村氏は振り返る。

ビジュアルセクションのチーム構成

鉄拳7開発プロジェクトのタイムライン

　開発を振り返ると，これまでのゲーム基板がPlayStationベースのシステム基板であったため，開発メンバーには開発機材として実機基板を提供していたが，今回はPCベースのシステム基板へと移行しており，さらにUE4もPCベースで動作するため，開発環境をPCベースで構築できたことは時間とコストの面でもUE4の採用はよい方向に働いたとしている。

鉄拳7のビジュアルコンセプト

ビジュアル部門の制作ボリューム

　また，UE4は，今も進化しているため，同じ鉄拳7というタイトルでも，表現品質を容易に上げることができるという，将来性や可能性も感じることができているという。鉄拳7の製品ライフタイム中のビッグアップデートのタイミングなどで，さりげなくグラフィックス表現がグレードアップしている……なんていうことが将来起こるのかもしれない。

UE4はグラフィックスエンジンとして活用し，ゲームコアは独立したモジュールとして開発

バンダイナムコスタジオ，鉄拳プロジェクト，リードプログラマ，工藤径氏

　「鉄拳7」開発プロジェクトにおける技術的側面については，リードプログラマの工藤径氏によって語られた。

　鉄拳7は，「多少のリスク」は想定したうえで進化途上のUE4の採用を決めたわけだが，そのリスクを最低限回避するために，独特なアーキテクチャ設計が行われている。
　それは，UE4のフル機能をあえて使わずに，UE4を純粋なグラフィックスエンジン（レンダラー）として使う……という設計指針だ。

UE4をレンダラーとして使うという大胆な設計指針を発案。実は，これは同時にリスク回避の意味もあった

　裏を返せば，鉄拳7は，UE4をフル活用していないわけで，鉄拳7開発プロジェクトサイドとしても「少々もったいない使い方だった」と振り返ってはいる。
　ただ，こうすることで，万が一，開発途上で「UE4を使わない」という決断をすることになったときに，鉄拳7開発が全面中止になってしまうことを最悪避けられる。つまり，UE4をレンダラーとしてしか使っていないのであれば，「UE4を使わない」としたときには，なんらかのレンダラーだけを用意すれば（多少のスケジュール遅れは許容するしかないにせよ）鉄拳7を形にはできる。
　工藤氏によれば，この「UE4のレンダラーとして活用する方針」を前向きに捉え，「これまで，増築と改良の積み重ねで進化してきた鉄拳シリーズのプログラムモジュール資産を，整理整頓するよい機会」としたようである。

鉄拳7のゲームコアはほぼ完全にUE4から独立したモジュールとして開発された

　いわばゲームプログラム部分は，これまでの鉄拳シリーズを継承して組み上げるということにも相当するので，鉄拳独特の操作感，プレイ感は確実に継承できるということになる。もしかしたら，ゲームメカニクス制御までが他社エンジン（この場合はUE4）になることで，「鉄拳感」が変化してしまう可能性を排除したかった……というのが本音なのかもしれない。
　結果的に，本講演では「鉄拳コア」と称された，鉄拳7のゲームメカニクスコア部分は独立したライブラリとしてビルドできる設計とし，プレイヤーからの入力制御，その入力をうけてのスクリプト処理とキャラクターの状態遷移制御，キャラクターのアニメーション計算と制御，衝突判定，カメラ制御（視点制御）までが，レンダラとして活用されるUE4から独立したモジュールとして構築された。

ワイヤーフレーム表示の簡易レンダラと組み合わせれば，こんな画面でも動作する

　鉄拳7のゲームコアはグラフィックス描画エンジンからほぼ切り離された設計となったことから，例えば描画エンジン側をワイヤーフレーム表示の簡易的なものに差し替えても，それでも動作してしまうという。木村氏は講演では語っていなかったが，それこそ，新世代版のNUライブラリのグラフィックスエンジンに将来的に差し替えていくことも技術的には可能ということなのだろう。
　なお，独立した鉄拳コアとレンダラーとしてのUE4以外に，鉄拳7の開発にあたっては，いくつかの定番ミドルウェアも活用している。

UE4とは別に，業界定番ミドルウェアも活用

　一つは業界標準ともいわれるUIデザインツール＆ミドルウェアの「Scaleform」だ。
　鉄拳7の開発は，UE4.1でスタートし，最終的にUE4.4でのリリースとなったわけだが，実は，UE4は，UE4.5から「Unreal Motion Graphics UI デザイナ」（UMG）と呼ばれるUI設計機能が搭載されている。UE4.5未満ベースで開発された鉄拳7にはこれが間に合わなかったというのが実情のようである。
　サウンドミドルウェアとして，これまた業界定番の「Wwise」を採用している。UE4にはサウンドオーサリングシステムが用意されておらず，サウンド開発チームがWwiseのオーサリングシステムを使いたかった……という現場の要望を汲んだことからの採用だったという。
　このほか，ムービー（動画）コンテンツのコーデックには定番の「Bink2」を採用している。
　鉄拳7開発プロジェクトが採用したこうしたミドルウェア群は，業界定番ということもあって，早期からミドルウェアメーカーがUE4への対応を表明しており，UE4と組み合わせて使うことに，大きな問題はなかったようである。

UE4と鉄拳コアの連携実現手法

　ほぼ独立単体動作も可能な鉄拳コアだが，実際の製品としては，UE4と鉄拳コアは相互連携できるように「統合」させる必要がある。
　この鉄拳コアとUE4を仲介する処理系は，当然ではあるが，鉄拳開発チーム自らが独自開発を行っている。

鉄拳コアはUE4から独立した存在

　例えば，鉄拳コアで処理されたキャラクターのアクション（アニメーション）は，UE4のアニメーションシステムにカスタムノードの形で組み入れている。
　視点制御（ゲームカメラ）は，鉄拳7開発チームが独自開発したモジュールで，UE4のカメラ制御をオーバーライドする設計としている。

UE4と鉄拳コアの連携は独自開発

　このほか，パーティクルエフェクトの発生，サウンドの発生，地形や背景との衝突情報の問い合わせ，ゲーム進行に応じたイベント発生時のUE4への通達なども，独自に開発された仲介処理系によって実装される設計となった。
　メインゲームとなる格闘部分以外のゲーム進行（ゲームシーケンス）パートも独自開発されている。これらをUE4側のゲームループ（EngineLoop）に組み込むことで，UE4の制御を離れたゲーム進行が制御されているというわけである。

　レベル（バトルステージ）の実装形態や読み込み（ローディング）方式については，UE4の特性から少しどうすべきか設計を悩んだそうである。
　例えば，バトルステージををゲーム終了まで永続的に存在し続ける（PersistentLevel）として用意して，そこでのバトルが終了して，続いて別のバトルステージを読み込んだりするような場合，UE4では，その読み込み中に非同期で何かの処理を実行継続させること（例えば動くローディング待機画面を表示するようなこと）が行えないことが分かったという。

図中の流れるメッセージ付きのローディング待機画面を実現するために特殊なステージデータ管理手法を採用した

　そこで，オブジェクトがなにも置かれてない真っ黒な，ダミーともいえるバトルステージを永続存在する大本のステージ（RootLevel）として設定し，ゲームで使用される全バトルステージを一つ一つ，そのダミー大本ステージのサブステージとして定義するという変則的な実装とした。
　つまり，各ステージは「地理的に（空間的に）はつながっていないが「データ管理上はご近所同士」……というような特殊な実装形態にしたということだ。この実装形態にすることで，各バトルステージの読み込みは，ゲーム進行を止めずに実行できるようになったというわけである。
　ただ，この実装形態にするとローディング時間が長くなったり，読み込み直後の初期化フェーズが高負荷になって，フレームレートが不安定になる（カク付きが発生する）ことがあったという。これは，ES3基板のOSであるWindows Embeddedのファイルキャッシュシステムに読み込みデータを載せるように工夫することで対処したそうである。なお，このようなUE4のダイナミックローディング終了後のカク付き問題は，UE4.8やUE4.9では改善がなされているとのこと。ちなみに，全バトルステージのデータをキャッシュに載せようとすると，約25GBのメモリが必要になるとのことだ。
　この実装形態だとバトルステージが増えていくと管理が複雑になっていくことが予想されるため，今も改善案を模索しているとのことである。

写真左上の作業画面に真っ黒な画面が描かれているがこれがダミーの大本ステージ。写真右下の画面中左の赤いリストが読み込まれて使用されているバトルステージ。それ以外の緑色のリストはデータ管理上はご近所のバトルステージ

「鉄拳7」グラフィックスの秘密

　鉄拳シリーズでは大部前から，衣装やアクセサリのカスタマイズが可能になっている。鉄拳7でもこの要素は継承することになり，各キャラクターの3Dモデルは，各部位ごとに管理される仕様となった。
　当初は面倒に思えたこの仕様の実装は，意外なことにUE4の基本機能を活用するだけで実現ができてしまったそうである。
　具体的には，UE4上で各キャラクターに共通の骨構造を設定し，そこに各部位モデルを定義していく（はめ込んでいく）ようなアプローチだ。この構造だと，ボーン制御およびボーンによって摂動させられる部位3Dモデルの処理が多重化され，CPU負荷が増加することも予測されたのだが，実際に動かしてみたところ，普通に動いてしまったので，このまま最終実装仕様としたとのこと。

キャラクターの衣装・アクセサリー装着システムは，部位パーツに分割し共通ボーンにはめ込んでいくような実装とした。苦労すると思われたこの機能の実装は意外にもUE4の仕様範囲で解決してしまったという

　日本のゲームグラフィックスは半透明を多用する傾向にあるが，鉄拳7もご多分に漏れず，その傾向が際立つことになった。具体的な半透明適用先としては，毛髪表現やほつれた衣服の裾先などがある。
　ただ，UE4で採用されているDeferred Renderingでは，先にジオメトリ（ポリゴン）を中間バッファ（G-Buffer）に，後段で行うライティング（光源処理）やシェーディング（陰影処理）に必要なパラメータと共に描画（先出し出力）してしまう。
　このレンダリングメカニズムは，実際のライティングやシェーディングを後段で行うからDeferred（遅らせた）Renderingという名前が付けられているわけだが，なんでこんな面倒なメカニズムをUE4が採用しているかというと，この手法には動的な光源をシーン内に無制限に配置できるというメリットがあるためだ。しかし，一方で，このレンダリング手法には半透明オブジェクトの取り扱いが不得意だという弱点もある。
　半透明オブジェクトは，「その背後のものが透けて見える」という特性上，視点から見て最奥端に存在するものから手前に向かって順番に描いていかないと正しい見え方で描けないわけだが，Deferred Renderingでは，そもそも半透明オブジェクトを想定していない。そのためUE4にはオブシェクトの細かい描画順序ソートの機能がない。
　そこで鉄拳7では，UE4の改造を行わずにDeferred Redneringメカニズムの範疇で，半透明表現の見た目を破綻させない実現方法を実践することにしたという。

鉄拳7が実装した，UE4における半透明描画手法

　その仕組みは具体的にはこうだ。
　まず，不透明オブジェクトをDeferred Renderingで描画するのだが，このときに描画対象ポリゴンが半透明を含んでいるかどうかを判定し，半透明を含んでいる部位のポリゴンであればそこに適用されるテクスチャを参照して，そのテキスチャ内の不透明領域だけをまずこのDeferred Renderingパスで描画する。
　UE4では，半透明オブジェクトについては，ライティングとシェーディングを同時に行いつつ描画していく，クラシックなForward Renderingで描画する仕組みになっているが，今度は，このForward Redneringパスで，先ほどの半透明を含んでいる部位のポリゴンの半透明領域だけを描画するようにする。
　つまり，「不透明領域と半透明領域が混在したテクスチャが適用されるポリゴン」（まさに裾先や毛髪のポリゴンなどがこれに該当）については，Deferred Renderingパスで不透明要素を描き，Forward Renderingパスで半透明要素を描くということだ。換言すれば，「不透明領域と半透明領域が混在したテクスチャが適用されるポリゴン」については，2回のパスに分けて描画する……ということだ。
　この描画方式を実装するにあたっては，キャラクターモデルの不透明/半透明混在部位のポリゴンを，データ構造上二重化してやる必要があるのだが，これについては，3DCGソフトからUE4にエクスポートする段階でそうした加工処理をしているとのことである。

半透明要素だけを描画したところ

不透明要素だけを描画したところ

二つを合成した最終仕様映像

　このほか，チャイナドレスのサテン生地に見られるような光沢がシフトする反射表現や，毛髪に出るいわゆる「天使の輪」的な光沢表現は，UE4に実装されてはいるものの活用されていなかった異方性反射機能を有効化して対応したという。

毛髪やサテン生地などの特殊素材にはハイライトがシフトするような異方性反射の表現を活用

　それと，格闘ゲームとしてプレイしたときに有利不利が生まれないように，背景のライティング条件に左右されずにキャラクターのシルエットを鮮明に見せる工夫として「キャラクター専用光源」を焚く工夫を，これまたUE4の仕様範囲内で実装したことについても触れられた。
　Deferred Renderingではシーン内にあるジオメトリ（ポリゴン）をすべて先に描画してしまうレンダリング手順のため，「特定の3Dモデル専用の光源」という光源でライティングすることはできない。シーン内に光源を置いたら，その光源はその照射範囲のすべてを無差別に照らしてしまう。実際，物理的にはそちらのほうが正しい。
　しかし，鉄拳7では，いついかなるときも，他者には影響を及ぼさず，自身専用の「各キャラクター専用光源」の効果を実現させたい。
　そこで，鉄拳7では，Deferred RenderingのG-Buffer生成フェーズにおいて，キャラクターの描画に際してはG-Bufferに「そのキャラクター専用光源のID番号」を書き出すようにして，後段のライティング/シェーディングフェーズでは，そのID情報が書かれているピクセルに関しては，追加でそのID番号に対応する光源でライティングするようにしたという。
　格闘ゲームに限らず，一般的なゲームでも，プレイヤーが操作する主人公キャラクターには，見映えをよくするための自分専用の光源をついて回らせる工夫をすることがあるが，鉄拳7では，この仕組みをDeferred Renderingのメカニズムから逸脱しない手法で実現するために「G-Bufferを媒介する仕組み」で対応したというわけである。

おわりに

　工藤氏や木村氏によれば，UE4での鉄拳7の開発を振り返ると，やはり高頻度に行われるバージョンアップへの追従が大変だったようである。エンジンの仕様変更などもあったり，その仕様変更で制作済みのコンテンツがうまく動かないことないかを検証したりするのが大変だったという。また，UE4がバージョンアップすると，それに遅れてミドルウェアのUE4対応プラグインがリリースされるので，UE4が進化してもすぐに最新版に移行できず「プラグイン待ち」になる局面もけっこうあったそうだ。

UE4のバージョンアップ時に発生したバグ取りには大分苦労させられたようだ。

　ちなみに，鉄拳7では，マスターアップ2か月前にUE4.4にアップグレードしたそうで，このときの苦労は相当なものだったそうである。
　今回の開発を経て，鉄拳7開発チームとしては，機能強化に伴うバージョンアップとは別に，「機能や仕様を据え置いた状態でバグフィクスだけを進めた安定動作版」がほしいと思ったそうである。なるほど，現場としてはもっともな意見である。
　一方で，予想以上にUE4の機能で感激させられたのは，ノードをつないでいくことでプログラミングが行えるUE4のビジュアルスクリプティングツール「BluePrint」（BP）のでき映えだったという。
　プログラマでなくとも，複雑な処理系を作り込むことができ，それでいてパフォーマンス面にも不満がないことを工藤氏は高く評価していた。なお，今回の鉄拳7開発プロジェクトでは，BPの処理速度が遅いと感じられたことはなく，むしろ開発チームの中には「BPでコーディングしていいのならばできるだけBPを使っていたい」と話したプログラマもいたそうだ。

鉄拳シリーズは，今後も，ゲーム面でも技術面でも進化を続けていく

　UNREAL FESTということで，現在，開発が進められているというバンダイナムコグループ独自のゲームエンジン「NUライブラリ」の新世代版についての言及はなかったが，今後，鉄拳シリーズがUE系でいくのが，NUライブラリベースに戻っていくのかは，気になるところではある。

「Unreal Engine」公式サイト

「鉄拳7」公式サイト