プリンセスメーカー2のケーススタディ：元のルールをiPadの体験へ

分析：原本のどこを変えられるか

REAはReverse Engineer Anythingの略で、AIエージェントが実行ファイルやアプリの構造を調べるための解析ツールをつなぐ。ネイティブプログラムではGhidraやHopperで関数と呼び出し関係を調査し、JavaScriptやElectronではモジュールとデータの経路を確認する。結果を根拠とともに残し、次の実装へ使う流れだ。

リバースエンジニアリング自体は以前から存在した。変わるのは作業の接続方法である。人が解析結果を読み、別の開発環境へ説明し直す過程にエージェントが加わり、同じ作業の中で機能を追い、説明し、新しい実装を試験できる。既存ツールと公開ソースの蓄積の上に、分析と開発をつなぐ通路が生まれた。

このプロジェクトにも具体的な調査記録がある。初期には16ビットDOS実行ファイルをGhidraで調べた関数・参照関係の記録があり、その後、画面リソースの選択とコピーを追う資料が加わった。公開されたPC-98版ソースも参照したが、韓国語DOS版と同一視せず、実行ファイルの動作と比較する必要があった。

分析は変更可能な位置を探すために使った。どのゲーム状態でどの絵が選ばれるかを知らなければ、新しい絵を正しい瞬間につなげられない。REAの役割は完成したiOSアプリそのものではなく、実装と試験が頼れる原本の動作の根拠を得ることだった。

実装：ゲーム実行を保ち、画面と操作をつなぐ

このアプリは原作の全ルールを新しく書き直したものではない。DOSBox Pureが元のゲームの実行、入力、保存、音声を担い、C++とSDLのiOSフロントエンドがタッチ操作と新しい画面を接続した。原本の実行を保ちながら端末との接点と表示を変えた構造だ。

この選択で目標が明確になった。既に動くルールと保存構造を使い、利用者が変えたかった画面と操作へ集中できた。古いプログラムを新しい端末で使う道には、このような組み合わせもある。分析ツールは、保つ部分と変える部分を判断する助けとなった。

画質改善には画像生成ツールで制作した絵を透過PNGに加工し、元のリソースと対応させた。背景と情報パネルの一貫性を保ち、キャラクターは年齢、教育、仕事、場所に合わせて変える必要がある。対応がずれれば、一画面がきれいでも次の場面で雰囲気や動きが途切れる。利用者の指摘を受け、場面の接続を修正した。

以下の比較は元の家事場面を進めたまま、背景、キャラクター、情報パネルの表現を変えたものだ。小さな装備・状態アイコンなどには元の表現が残っており、全場面の絵を置き換えたという意味ではない。

結果：実機iPad miniでセーブを再開する

注目したいのは作業の終点である。Codexは分析の説明から、画像制作と加工、場面の接続、コード修正、試験、iOSのビルドと署名、iPadへのインストールまで進めた。解析、画像生成、コンパイラ、端末管理の各ツールを一つの作業の流れで使い、実機で再び動かせるアプリを届けた。

インストール前にはセーブをバックアップし、更新前後でゲーム・ランタイムの67ファイルのハッシュ一致を確認した。最終報告はデスクトップの実行フロー54検査とiOSシミュレーター9検査の通過を記録する。実機iPadでは起動、セーブ再開、新しいホーム画面を確認した。対象版と試験項目の結果であり、全分岐や全端末の完全な検証ではない。

作業は何度も修正と検査を重ねた。画像の一貫性を見直し、容量不足で中断した検査も再開した。人は目標と好みを示して結果を判断し、端末接続とアクセス条件も必要だった。Codexが全工程を担ったとは、この条件の下で分析からインストールまで技術的実行を続けた意味であり、人の判断や既存ソフトウェアの貢献が消えたわけではない。

この区別により変化が具体的になる。利用者は全分野を習得して各工程を自ら行う代わりに、望む結果と許容できない誤りを説明することへ集中できた。AIの実行範囲が広がるほど、人の要求を試験可能な条件へ変える力が重要になる。

残る範囲：場面の一貫性とセーブの連続性

改善した一画面は全場面の品質を保証しなかった。繰り返し確認したのは原本が選んだ動作と新しい絵の対応だ。背景、キャラクター、情報パネルが同じ状態を説明し、旧セーブの進行も続く必要がある。起動できることと長時間のプレイで問題がないことの間には、追加試験が残る。

比較GIFは実際のデスクトップ検証時の画面を使う。ホーム画面は同じセーブ状態の静止画像を交互に表示し、家事場面は実行フレームを順番に示す。中間の動きを新しく合成した映像ではない。実機iPadの結果は冒頭の端末キャプチャとインストール・検証記録で区別している。

個人制作の事例は、元のゲームファイルや第三者の絵・コードを再配布する許可を意味しない。原本の実行、新しく書いた画面コード、新しい絵、外部資料を分けて管理することも開発成果の一部である。

教訓：作り直す範囲を先に決める

筆者の最初の教訓は、望む体験のために全てを作り直す必要はないということだ。ルールと保存構造を残し、画面と入力を変える選択で目標を絞れた。REAは介入位置の根拠を提供し、Codex Workはそれを制作、検査、インストールへつないだ。

次のプロジェクトでも、残す部分、変える部分、実機で通すべき条件を先に決めたい。利用者は望む結果と許容できない誤りを示し、エージェントは実装と反復検査を続ける。この役割の変化は一度のデモより重要な成果だ。

開発企業の競争力も同じ視点で考えられる。似た機能を作る速度とともに、過去のファイルの互換性、安定した更新と復旧が重要になる。REAの関数復元とArtCraftの公開編集ツールは、以下の別のケーススタディで詳しく扱う。