DeepSeekの新モデルをツール実行型のAIエージェントにつなぎ、Android端末でWindows版『BIOHAZARD 7 resident evil』を軽量化する個人デモが公開された。投稿者はテクスチャ群を20GBから8GBへ縮小し、ゲーム全体を13GBにしたと説明している。Wccftechは投稿者への追加取材として、OnePlus 12Rで約20FPSだった動作が安定した30FPSへ上がったと報じた。ただし、これはAIモデルだけの性能試験ではない。テクスチャ縮小とSGSRが併用され、内部解像度や熱状態など変更前後の条件も不明なため、成果の読み方には慎重さが要る。
個人デモでAIエージェントは何を変えたのか
発端は2026年9月14日のX投稿である。投稿者はDeepSeek V4.1 FlashとHermes Agentを使ったと明記し、20GBあったテクスチャ群を8GBへ圧縮したと説明した。改変後のゲーム全体は13GBで、iOS版は約25GBだとも記している。公開投稿から直接確認できるのはここまでで、プロンプト、変換スクリプト、変更一覧、実行ログは示されていない。
翌15日のWccftechは、投稿者への追加取材として作業の内訳を伝えた。OnePlus 12RをMacへUSB接続してデバッグし、4,096ピクセルのテクスチャを1,024または512ピクセルへ下げ、一部の音声やスキンも取り除いたという。さらにSnapdragon Game Super Resolution（SGSR）で720pから1200pへ拡大し、以前はかろうじて20FPSだった動作が安定した30FPSになったとする。消費電力は5〜6Wと報告された。これらの数値は元のX投稿本文にはないため、公開ログで検証済みの値ではなく、Wccftechが追加取材で得た投稿者の説明として扱う必要がある。
AIが担った役割も分けて考えたい。DeepSeek V4.1 Flashは2026年9月10日に公開されたMoEモデルであり、Hermes Agentはモデルそのものではない。HermesはLLMに端末操作、ファイル操作、コード実行などの道具を渡す実行基盤である。今回の構図は、DeepSeekが診断や手順の生成を担い、Hermesが外部操作を仲介したものと読める。ただし、どの道具を有効にし、どこで人間が承認・修正したかは公開されていない。完全自律の最適化とまでは確認できない。
Winlatorではどこに負荷が積み上がるのか
OnePlus 12RはSnapdragon 8 Gen 2、Adreno 740、8GBまたは16GBのLPDDR5Xメモリを搭載する。どちらのメモリ構成を使ったか、AndroidやGPUドライバの版、空き容量は不明だ。端末は2024年1月23日に発表されており、デモ時点では約2年8カ月が経過している。Wccftechの見出しは「4年前のスマートフォン」とするが、端末の年齢としては合わない。Snapdragon 8 Gen 2の発表が2022年11月15日だったため、約3年10カ月というSoC世代を丸めた表現に近い。
この端末でPC版を動かす経路は長い。WinlatorはWineとBox86／Box64を組み合わせ、Android上でWindows向けx86_64アプリを動かす。Box64はARM64上でx86_64命令を動的に変換し、Wine64を支える。ゲームがDirect3D 8〜11を使えば、DXVKが描画命令をVulkanへ変換し、その先でAdreno向けドライバがGPUを動かす。CPU命令の変換、Windows APIの互換処理、描画APIの変換、資産の読込み、GPU処理が連なる構成だ。
したがって、Wccftechが投稿者の説明として挙げたI/Oまたはメモリ帯域の制約は、技術的にはあり得る。しかし、プロファイラの結果は公開されていない。テクスチャを小さくすれば保存容量だけでなく、読込み量やGPUメモリへの転送量も減り得る。一方で、音声やスキンを除けば内容は同一でなくなる。公式版と同じ品質・内容を保った比較ではない。Steamが示すPC版の現行最小要件は24GBの空き容量、1080p／30FPSであり、投稿者の13GBは公式配布版の要件が変わったことを意味しない。
「50％向上」をAIの効果と断定できない理由
20FPSから30FPSへの増加率は、(30-20)÷20=50％である。だが、同じ場面を同じ時間だけ走らせたのか、Winlator、Wine、Box64、DXVK、GPUドライバの版が同じか、変更前後の内部解像度と端末温度がそろっていたかは分からない。平均FPS、1％低位値、フレーム時間、反復回数も公開されていない。DXVKにはFPSやフレーム時間を表示する機能があるものの、このデモの生ログはない。
元投稿が示すテクスチャ容量は20GBから8GBで、削減率は60％である。Wccftechの見出しにある68％は、本文に出る25GBから8GBを計算した値だが、25GBは元投稿ではiOS版の容量として書かれている。計算式はそれぞれ(20-8)÷20=60％と(25-8)÷25=68％になる。ところが、いずれの容量も投稿者の申告で、ファイル一覧や実バイト数は公開されていない。iOS版と改変したWindows版は配布形式や同梱内容も同じではなく、25GBと8GBを並べても同条件の圧縮率にはならない。
5〜6Wという値にも分母がない。SoCだけの電力なのか、端末全体なのか、ソフトウェアによる推定なのか、外部機器による測定なのかは示されていない。変更前の電力値もないため、効率が何％上がったかは計算できない。複数の変更を一度に加えた結果から、DeepSeekの判断、テクスチャ縮小、ファイル削除、SGSR、発熱に伴う性能制限の緩和が、それぞれ何FPSに相当したかを分離することはできない。
SGSRで1200pはネイティブ1200pを意味しない
SGSR1は、現在の1フレームを入力に使う1パスの空間アップスケーラーである。upscaling（アップスケーリング、低い内部解像度から高い出力解像度へ拡大する処理）と鮮鋭化を単一のシェーダーパスへまとめ、低い解像度で描いた画像を大きな出力へ変換する。時間方向の情報を使うSGSR2とは別の方式だ。
そのため「720pから1200p」は、1200pの全画素を最初から描画したという意味ではない。低い内部解像度でGPU負荷を抑え、1200p相当の出力へ拡大したと読むべきである。QualcommはSGSR一般について性能向上をうたっているが、そのデモ値を今回のWindowsゲーム実行系へ移すことはできない。どの版を、どのシェーダー設定でWinlator側へ組み込んだかが未公開だからだ。
一般に、テクスチャ縮小と内部解像度を下げる操作は、別の負荷を変える。前者は資産容量、読込み、メモリ使用量に効き得る。後者は主に描画する画素数を減らす。今回のようにテクスチャ縮小とSGSRを併用した結果だけでは、30FPSへ届いた主因も、画質への影響も切り分けられない。静止画の解像感だけでなく、動きの中でのちらつきや輪郭の安定性も確認が要る。
再現可能な成果にするために必要な公開情報
この事例の価値は、汎用のAIモデルとツール実行基盤が、ゲーム資産の調査、変換作業、端末上の確認をつなげ得ると示した点にある。だが、再現可能な技術成果にするには、成功映像だけでは足りない。使用したプロンプトと道具、変換スクリプト、対象ファイル一覧、WinlatorからGPUドライバまでの版、ゲーム設定、内部・出力解像度をそろえて公開する必要がある。
測定も固定しなければならない。同じセーブデータと場面、同じ走行経路、同じ初期温度、同じ測定時間で複数回実行し、平均FPS、1％低位値、フレーム時間分布、温度、クロック、端末全体の電力を変更ごとに記録する。まずテクスチャだけ、次にファイル削除、最後にSGSRという具合に一要素ずつ加えれば、どの変更が何を改善したかを追える。
AIエージェントが実機の複雑な最適化を支援できる可能性は見えた。ただし、可能性を製品評価へ変えるのはモデル名でも一度の50％向上でもない。第三者が同じ入力と手順から同じ違いを再現できるかどうかである。
