2026年9月、AnyPS5という新しいプロジェクトが話題になりました。
PS5のゲームをPCで動かす取り組みなのですが、これまでのエミュレーターとは方式がまったく違います。
開発者自身、これをエミュレーターとは呼んでいません。
なぜそんなことが可能になったのか。
理解するには、PS1からPS5までの30年近い歴史を追う必要があります。
初代PlayStationの頃と今とでは、PC側で再現しなければならないものが大きく変わってきたからです。
この記事では、まず各世代のエミュレーションがどう変化してきたのかを整理し、最後にAnyPS5という新しい方式がどこまで進んでいるのかを見ていきます。
エミュレーターとは何なのか
ゲーム機のCPUやGPU、システム機能をPC上で再現する
エミュレーターと聞くと、ゲーム機を丸ごとソフトウェアでコピーしたもの、という印象があるかもしれません。
実際にはもう少し複雑で、複数の技術を組み合わせて成り立っています。
CPUの命令を変換する部分、GPUの描画命令をPCのグラフィックスAPIに置き換える部分、ゲーム機のシステム機能を代わりに用意する部分。
それぞれ別の課題で、別の解き方をします。
エミュレーターと互換レイヤーは同じではない
ここは混同されやすいところです。
エミュレーターは、本来そのハードウェアでしか動かないプログラムを、別の環境で動かすために内部の動作を再現します。
一方、互換レイヤーはOSやライブラリの機能を置き換える仕組みで、CPUの命令そのものは変換しません。
後で出てくるPS4・PS5世代の話では、この区別が重要になります。
JIT・再コンパイル・ネイティブ実行の違い
CPU命令の扱い方には、大きく分けて3つの段階があります。
ひとつはインタプリタで、命令を1つずつ読み取って解釈します。正確ですが遅いです。
次にJIT（動的再コンパイル）で、ゲーム機のCPU命令をまとめてPCのCPU命令へ変換します。現代のエミュレーターの多くがこれを使っています。
そしてネイティブ実行は、そもそも変換せずにそのまま実行する方式です。これはゲーム機とPCのCPUが同じ命令体系を使っている場合にしか成立しません。
PS4以降で状況が変わったのは、まさにこの部分です。
PS1エミュレーターは1990年代から存在した
Bleem!とConnectix VGS
1999年、商用のPS1エミュレーターが2つ登場しました。
Windows向けのBleem!は1999年3月にデモが公開され、4月に製品化されています。
Mac向けのConnectix Virtual Game Stationも同年に登場しました。
どちらもソニーから訴訟を起こされています。
特にSony対Connectixの裁判は、エミュレーション史における重要な判例になりました。
米国第9巡回区控訴裁判所は、Connectixが互換ソフトを開発する目的で行ったBIOSの中間コピーについて、その事件の事情ではフェアユースにあたると判断しています。
ただし注意したいのが、これはエミュレーター全般を合法化した判決ではないという点です。
ゲームROMやBIOS、ファームウェアの入手方法まで含めて認めたわけではありません。
ePSXeとPCSXがPS1エミュレーションを広げた
2000年前後になると、無料で使えるエミュレーターが登場します。
ePSXeとPCSXです。
PCSXは2000年8月31日に初版が公開されました。
そして2001年半ばには、PCSXを開発していた開発者たちがPS2エミュレーターのPCSX2を開始しています。
PCSX本家の開発が終了したのは2003年頃で、その後にPCSX-Reloadedのようなフォークへ派生していきました。
ePSXeは今も更新が続いていて、2025年12月にWindows版の2.0.18が公開されています。
昔のソフトとして完全に終わっているわけではない、という点は押さえておきたいところです。
現在はDuckStationやBeetle PSXが存在
現代のPS1エミュレーションを担っているのがDuckStationです。
2019年に登場した比較的新しいプロジェクトで、JITによるCPU再コンパイル、Vulkan・Direct3D・OpenGL・Metalへの対応、アップスケーリング、PGXPによるポリゴン揺れの補正などを備えています。
もうひとつがBeetle PSX系です。
こちらはMednafenのPSXモジュールから派生したもので、通常版は精度重視、HW版はVulkanやOpenGLによる高解像度化に対応しています。
ここで重要なのは、PS1のCPUが32bitで、現在のPCとは命令体系がまったく違うという点です。
DuckStationがCPU再コンパイラを搭載しているのは、そのためですね。
PS2ではPCSX2が20年以上進化してきた
PS2エミュレーションの中心にあるのがPCSX2です。
開発が始まったのは2001年半ばで、2026年現在も現役。8月28日に2.8.0が公開されています。
20年以上続いているプロジェクトということになります。
Emotion EngineをPCで再現する仕組み
PS2はPS1より構成が複雑になりました。
CPUにあたるEmotion Engine、描画を担当するGraphics Synthesizer、さらに複数の演算ユニットを扱う必要があります。
ソニー自身、Emotion Engineを8つの個別ユニットで構成されるCPUと説明しています。
PCSX2は公式に、MIPS CPUのインタプリタ、再コンパイラ、仮想マシンを組み合わせてPS2のハードウェアとメモリ状態を再現していると説明しています。
つまり、ここでもJITと再コンパイルが中心技術です。
現在のPCSX2はどこまで動くのか
互換性データベースでは2,500タイトル以上がテストされていて、多くのゲームをフルスピードで動作させられる水準に達しています。
さらに、内部解像度を上げて実機より高い解像度で描画する機能もあります。
長年の蓄積によって、かなり成熟した段階に来ていると言えます。
Play!という別系統もある
PCSX2とは別に、Play!というプロジェクトも存在します。
Windows、macOS、Linux、Android、iOS、さらにWebブラウザまで対応しているのが特徴で、独自のHLE BIOSを内蔵しています。
2006年の開発ログが残っているので、こちらもかなり長く続いているプロジェクトです。
PS3のCellでエミュレーション難易度が大きく上がった
Cell Broadband Engineが特殊だった理由
難易度を押し上げた原因はCell Broadband Engineという独自のプロセッサです。
Cellは通常のPowerPC系コア（PPE）と、複数のSPEという演算ユニットを組み合わせた異種混合型の設計でした。
厄介なのはSPEの構造です。
SPEは独自のLocal Storeという専用メモリを持っていて、通常のメインメモリにアクセスするには明示的なDMA転送が必要でした。
つまりエミュレーター側は、CPU命令体系の違いに加えて、PPEとSPEの並列実行、Local Store、DMA、タイミングや同期、そしてRSXというGPUまで再現しなければなりません。
性能が高かったから難しかった、という話ではなく、PCとは構造がまったく違ったから難しかったわけですね。
RPCS3はどのように成熟してきたのか
それでも、RPCS3というプロジェクトが2011年から開発を続けてきました。
そして2026年7月14日時点で、互換性データベースの3,559エントリのうち2,681、割合にして約75%がPlayableに到達しました。
ここで注意したいのが、この75%という数字の意味です。
PS3ソフト全体の75%が動く、という意味ではありません。
RPCS3の統計はタイトル単位ではなく、ゲームIDをメディアごとにまとめて集計しています。
つまり、同じゲームでもディスク版とデジタル版は別のエントリとして数えられます。
なお、2026年8月時点の最新値では3,560エントリ中2,758がPlayableとなっていて、現在も数字は伸びています。
さらに2026年9月には、対応するBlu-rayドライブからPS3ゲームを直接起動する機能も追加されました。
霊夢PS3が一番難しかったっていうのは意外ね
魔理沙性能が高かったからじゃないのか？
霊夢そうじゃないの。CellっていうCPUの構造が、PCとまったく違ったからよ。SPEっていう演算ユニットが専用メモリを持ってて、データを移すのにも特別な手続きが要ったの
魔理沙なるほどな。速いかどうかより、形が違うかどうかってことか
PS4でCPUがx86-64へ変わった
PS3までとの大きな違い
PS4のCPUはAMD Jaguarベースのx86-64になりました。
これは一般的なPCと同じ命令体系です。
PS1のMIPS、PS3のCellと違って、PC側でCPU命令を別の体系に翻訳する必要が大きく減ったわけです。
shadPS4はCPUをネイティブ実行する
この特徴を活かしているのがshadPS4というプロジェクトです。
公式の設計資料によると、x86-64のPC上ではPS4のCPUコードをエミュレートせず、そのままネイティブ実行します。
その代わり、PS4のシステムライブラリを互換レイヤーとして再実装しています。
それでもGPUなどのエミュレーションは必要
ここで誤解しやすいのですが、CPUをエミュレートしない＝PS4を一切エミュレートしていない、ではありません。
GPU側については、PS4のPM4コマンドなどを解析してVulkanの描画命令へ変換する処理が必要です。
だからshadPS4自身も、自分をエミュレーターと位置付けています。
そして公式は2026年時点でも「開発の初期段階」としていて、多くのゲームは動作せず、動くゲームにも問題があると明記しています。
x86-64になったから簡単になった、という単純な話ではないわけですね。
PS5エミュレーターは現在どこまで進んでいるのか
PS5もAMD Ryzen Zen 2ベースのx86-64で、GPUはRDNA 2ベースです。
KytyPS5
旧Kytyを大幅に改変した現行のPS5エミュレーターです。
公式の説明によると、2Dゲームと一部の3Dタイトルを起動できる段階まで来ています。
ここで気をつけたいのが、In gameという表記の意味です。
KytyPS5におけるIn gameは「操作可能なゲームプレイまで到達した」という意味で、クリアできるという意味ではありません。
バグで最後まで進めなくても、In gameになります。
なお、改造されたKytyPS5のビルドで特定タイトルが40〜60fps近くまで動作したという第三者のSNS報告もありますが、これは公式ビルドの標準的な性能ではない点に注意が必要です。
SharpEmu
2026年に登場したC#製のプロジェクトです。
実ゲームのeboot.binを読み込み、x86-64のCPU命令をネイティブ実行しつつ、GPU機能を部分的に実装しています。
互換性データベースの数字が現状をよく表しています。
2026年9月28日時点で、登録9,092タイトルのうちテスト済みは56件。
内訳はNothing 14件、Boots 22件、Menus 6件、Ingame 7件、Playable 7件です。
9月27日には、DOOM + DOOM IIがPlayableとして追加されています。
RPCSX
PS4とPS5の両方を対象にした実験的なプロジェクトです。
公式FAQでは、少数のタイトルがIn-gameとされています。
Windowsについては、現時点ではWSL経由での動作という状況です。
まだ広く実用段階とは言えない
3つのプロジェクトを並べると、現状が見えてきます。
起動するタイトルは出てきているものの、PS5のゲームをPCで普通に遊べる段階には達していません。
SharpEmuのPlayable 7件という数字が、現在地を端的に示していると思います。
AnyPS5は従来のPS5エミュレーターとは違う
AnyPS5は、ここまで見てきたエミュレーターとは根本的に方式が違います。
PS5実行ファイルをPC向けに変換する
公式のREADMEによると、AnyPS5は自身を「Linux/Windowsへの実行ファイル自動移植ツール」と説明しています。
処理の流れはこうです。
PS5の実行ファイルをrelinkerという仕組みに通し、LinuxやWindowsのネイティブ実行形式へ変換する。
そこにPS5用ライブラリの代替実装をリンクして、PC上で実行する。
公式READMEには明確に「エミュレーションも別のランタイムプロセスも使わない」と書かれています。
つまり、実行中に仮想的なPS5環境を用意するのではなく、事前に実行ファイルそのものをPC向けに作り変えるというアプローチです。
PRXライブラリをPC側の実装に置き換える
PS5のゲームは、PRXという形式のシステムライブラリを使っています。
AnyPS5では、システムPRXの代替実装を動的リンク向けのライブラリとして用意します。
一方、ゲーム自身が持つモジュールについては変換したうえでリンク時に優先する扱いで、一部は事前のバインドを要求します。
すべてを同じ方法で処理しているわけではない、という点は押さえておきたいところです。
x86-64だからCPU命令の変換を大きく減らせる
この方式が成立する理由は、PS5のCPUがPCと同じx86-64だからです。
MIPSからx86、PowerPCからx86のように命令体系を丸ごと変換する必要がありません。
PS1やPS3の時代には、絶対に取れなかった手段ですね。
ただし、完全に無変換というわけでもありません。
AnyPS5には--to-intelというオプションがあり、Zen 2には存在するけれどIntel製CPUではそのまま使えない命令を、変換時に書き換える処理が用意されています。
同じx86-64でも、メーカーによって使える命令に差があるためです。
GPUとシェーダーは依然として大きな課題
CPU側の変換が減っても、GPUまでそのまま動くわけではありません。
AnyPS5でもシェーダーの再コンパイルが必要になります。
ここがこの方式でも避けられない部分です。
霊夢実行ファイルを先に作り変えちゃうっていう発想なのね
魔理沙エミュレーターとは逆の考え方か？
霊夢そうとも言えるわ。エミュレーターは実行中にPS5の環境を用意するけど、こっちは動かす前にPC用のプログラムに変換しちゃうの
魔理沙CPUが同じだから成立する方法ってことだな
AnyPS5は現在どこまで動いているのか
9月25日の報道時点では証拠が示されていなかった
2026年9月25日、海外メディアがAnyPS5について報じました。
当時のGitHubの記述を根拠として、実際のPS5ゲームがゲームプレイまで到達し、音声も動作したという開発者側の主張が紹介されています。
ただしこの時点では、その記事自身が「まだ証拠は示されていない」と明記していました。
現在のREADMEではゲームプレイ到達が記載されている
その後、公式READMEは更新されています。
2026年9月28日時点の記述では、シェーダーリコンパイラがSPIR-Vを生成できることに加えて、実際のゲームがロゴからメインメニュー、そしてゲームプレイまで到達し、音声も動作すると明記されています。
つまり、数日前の状態からは進んでいます。
AnyPS5を使った実装が公開された
さらに9月27日、AnyPS5を利用した別のプロジェクトが公開されました。
PS5版Dead Cellsのx86-64コードをWindows実行ファイルへ変換し、GPUシェーダーをVulkanへ再コンパイルするというものです。
プロジェクト側の説明では、ロゴからゲームプレイまで動作し、音楽や効果音も動作するとされています。
ソースコードと実行用パッケージの利用手順も公開されました。
ただし、この動作を第三者が独立して検証した結果までは確認できていません。
外部から試せる実装が出てきた段階、という理解が適切だと思います。
AnyPS5本体はまだ正式リリースされていない
一方で、AnyPS5そのものには正式リリースがありません。
最低1本のゲームが完全に起動するまでリリースしない、という方針が示されているためです。
整理すると、こうなります。
AnyPS5本体の正式版はまだ存在しない。
ただし、この方式を使った個別タイトル向けの実装は公開され始めている。
数日単位で状況が変わっているので、最新の情報は公式GitHubを確認するのが確実です。
PS1からPS5までで何が変わったのか
CPU命令変換が必要だったPS1〜PS3
PS1のMIPS、PS2のEmotion Engine、PS3のCell。
いずれもPCとは異なる命令体系だったため、エミュレーターはCPU命令を変換する必要がありました。
インタプリタからJIT、再コンパイルへと技術は進化しましたが、変換という作業自体は避けられませんでした。
CPUをネイティブ実行できるPS4・PS5
PS4でx86-64になったことで、この前提が変わります。
shadPS4はPS4のCPUコードをネイティブ実行しますし、SharpEmuもPS5のCPU命令をそのまま実行します。
そしてAnyPS5は、さらに踏み込んで実行ファイル自体をPC向けに変換するという方式を取りました。
エミュレーションが消えたのではなく対象が変化した
「PS4以降はエミュレーションが不要になった」というのは、正確ではありません。
CPU命令の変換は大きく減りましたが、代わりにシステムライブラリの再実装、GPUコマンドの変換、シェーダーの再コンパイル、OSサービスの代替といった課題が残っています。
shadPS4が今も開発初期段階にあるのが、その証拠ですね。
エミュレーションが消えたのではなく、PC側で再現しなければならないものが変わった。
これが、PS1からPS5までの30年近い変化の本質だと思います。
AnyPS5という新しいアプローチも、その延長線上にあります。
このジャンルは動きが速いので、今後の進捗にも注目したいところです。
