ゲームの移植とマルチプラットフォーム｜AIゲーム開発のスマホ・Web対応

2026年10月4日

ゲームを Steam で出したあと、「ゲーム機やスマートフォンでも遊びたい」という声が届くことがあります。別の機種でも遊べるようにする作業が移植です。工程の上では発売と運用の後ろに置かれますが、どの機種に出すかの見込みは、企画やエンジン選びの段階から作りに効いてきます。全体の中での位置は「ゲーム開発の全工程マップ」で確認できます。

本記事では、移植の判断から、機種ごとの違い、移植しやすい作り方、AI を使う場合の進め方までを解説します。規則と料金は2026年10月時点の各社の公式ページによります。契約や規約の説明は一般的なもので、法的な助言ではありません。最終的な確認は、公式の規約・契約と専門家で行ってください。

夕宮たいだ

ふぁ……みんな〜、今日は「移植」の話だよぉ。機種が変わると、操作も画面も決まりも変わるんだぁ。順番に見ていこ〜。

移植とマルチプラットフォームとは

ひとことで：移植は作ったゲームを別の機種で遊べるようにする作業で、マルチプラットフォームは複数の機種に出すことです。

ここでいう機種（プラットフォーム）は、ゲームが動く土台と売る場所の組み合わせです。Windows と Steam、ゲーム機と本体のストア、iPhone と App Store、ブラウザと自分のサイト、といった単位で考えます。移植（ポーティング）は、見た目や中身を作り直すリマスター・リメイクとは分けて使われることが多い言葉です。目的は主に次の3つです。

遊べる人を増やす：機種が変われば、そこで遊ぶ人も変わります
売上の柱を増やす：1つのストアの売れ行きに左右されにくくなります
作品を知ってもらう機会を増やす：別の機種での発売や、ブラウザで遊べる版が、新しい入口になります

移植をいつ考えるか

ひとことで：出すのは後からでも、移しやすい作りは最初から入れておくのが、少人数では負担の少ない進め方です。

	最初から複数の機種に出す	1つの機種で出してから移す
利点	同時に発売でき、宣伝をまとめられる	売れ行きと評価を見てから費用をかけられる
欠点	確認と手続きが機種の数だけ増え、発売前に重なる	移しにくい作りのままだと、作り直しが大きくなる
向く場合	パブリッシャーが付き、体制がある	個人・少人数の最初の作品

個人や少人数なら、まず PC（Steam）で出し、後で紹介する「移しやすい作り」だけは最初から入れておく折衷が現実的です。エンジンごとの書き出し先は「ゲームエンジンの選び方と開発環境」を参考にしてください。

移植するかの判断

ひとことで：その機種との相性、売上の見込み、費用、期間を並べ、費用を回収できるかで決めます。

観点	確かめること
相性	その機種の操作と遊ぶ場面で、遊びが成り立つか。例えば、文字の多いノベルゲームは、テレビで読める大きさにすると1画面に入る行数が減る
売上の見込み	元の版の売れ行きとレビューの要望、移植先で同じジャンルがどう扱われているか
費用	作業時間、開発機材、エンジンの条件（例：Unity でゲーム機に出すには、Unity Pro〔2026年10月時点で年2,310ドル・1席〕などが要る）、年齢区分、翻訳、外注費
期間	登録と承認、作業、認証・審査と差し戻し、元の版の更新との両立

見積もったら、「移植の費用 ÷ 1本あたりの手取り（価格からストアの取り分・税・分配を引いた額）」で、回収に必要な本数を出します。届きそうになければ、見送るか、外部に任せる形を考えます。決めきれないときは相性を優先します。遊びが成り立たない移植は、作品の評価を落としかねないからです。

移植するかを判断する4つの観点（相性・売上の見込み・費用・期間）と3つの結論（自分で移植・移植会社やパブリッシャーに任せる・見送る）、回収に必要な本数の式 — 図1：相性・売上の見込み・費用・期間を順に確かめ、自分で移植するか、任せるか、見送るかを決める

移植の進め方と完了の条件

ひとことで：登録と契約から提出まで6つの段階で進め、全部の機種で同じ内容を出せる状態になったら完了です。

① 登録と契約：ゲーム機は各社への開発者登録、スマートフォンはストアへの登録が先です
② 技術の下調べ：エンジンの書き出し、使っている部品（プラグイン）や言語が動くか、性能が足りるかを小さな試作で確かめます
③ 差の吸収：機種の違いを1か所で吸収し、移植先で最後まで動かします
④ 体験の作り直し：操作、UI の配置、文字の大きさ、1回に遊ぶ長さを機種に合わせます
⑤ 実機のテスト：性能、読み込み、中断と再開を実際の機器で確かめます
⑥ 提出：年齢区分とストアの準備をして、認証・審査に出します

完了の条件は、移植先の認証・審査を通ったこと、元の版と同じ内容が遊べること（違いは意図して変えた所だけ）、実機で最後まで通して遊んだこと、修正を全部の機種へそろえて出す手順が決まっていることです。

機種ごとの違い

ひとことで：入力・画面・保存・認証・年齢区分・契約のそれぞれに、PC 版にない決まりがあります。

観点	Steam Deck	家庭用ゲーム機	スマートフォン	Web（ブラウザ）
入力	コントローラー	コントローラー	タッチ	端末しだい
画面	1280×800 の小さな画面	離れて見るテレビ	縦長で、切り欠きがある	大きさと向きが変わる
保存	PC と同じ（Steam クラウド）	本体の仕組みに従う	裏に回ったまま終了されることがある	保存領域が消されることがある
出すための確認	互換性の評価（表示のみ）	開発者登録・契約・認証	ストアの審査	公開先の決まり

入力・画面・文字の大きさ

Steam Deck やゲーム機ではコントローラーだけで、スマートフォンでは指だけで、すべての画面を操作できる必要があります。Xbox の要件（XR-003）の手引きにも、ゲーム機ではコントローラーだけで全画面を操作できること、とあります。カードゲームのドラッグを「十字キーで選んでボタンで出す」形にしたり、アクションの照準に「近くの的に寄せる補助」を足したりと、入力の違いは遊びそのものに関わります。

文字は、画面からの距離で必要な大きさが変わります。マイクロソフトのアクセシビリティの指針（Xbox Accessibility Guideline 101。要件ではなく推奨）は、起動時の文字の最小の大きさを次のように示しています。

機器	文字の最小の大きさ
ゲーム機（テレビ）	1080p で 26px（4K で 52px）
PC	1080p で 18px（4K で 36px）
スマートフォン	100 DPI で 18px。DPI に比例して大きくする

Steam Deck の「認証済み」の条件は、1280×800 で最小 9px（推奨 12px）です。PC 版の文字をそのまま縮めると読めなくなるので、文字の大きさは設定で変えられるようにしておきます。

性能・保存・通信

性能は、いちばん弱い機器に合わせます。Xbox では、同じ世代の上位機と下位機の両方に同じ遊びを出すこと（XR-130）が求められます。保存では、Steam のクラウド保存で画質など機器ごとの設定を同期しないよう、公式が案内しています。通信では、サービスにつながらなくても落ちずに利用者へ知らせること（XR-074）など、機種ごとの決まりがあります。

認証と審査

ゲーム機では、発売前にプラットフォーム側の認証を通します（任天堂＝ロットチェック、ソニー＝TRC、マイクロソフト＝XR に基づく認証）。任天堂とソニーの細かい要件は、開発者向けの非公開の資料にあります。公開されている XR から、移植で効く例を挙げます（2026年9月8日の Version 16.4）。

要件	内容の要点
XR-055	発売時に実績を10〜100個そろえ、ゲーマースコアを1000にする。実績のない作品は追加が要る
XR-115	遊んでいる最中にコントローラーが外れたら、別のコントローラーで再開できるようにする
XR-074	サービスにつながらなくても、落ちたり固まったりせず、利用者に知らせる
XR-022	本体・機能・周辺機器は、決められた用語集の呼び方で書く

Steam は認証ではなく審査（通常3〜5営業日。公式は7営業日前の申請を推奨）で、承認された後のビルドの更新は審査し直されません。App Store は更新も審査します。提出用のビルドの仕上げは「マスターアップとは」で扱います。

夕宮たいだ

ロットチェック、TRC、XR……呼び方がばらばらで、むずかしいねぇ。どれも「その機種の決まりを守れているか」の確認なんだぁ。

年齢区分

出し先	取り方（2026年10月時点）
国内のゲーム機（パッケージ）	CERO の審査
国内のゲーム機（ダウンロード専用）	条件つきで IARC でも出せる（18歳以上向けなどは CERO）
Steam	CERO は不要。Steam の内容申告から区分が付く（ドイツでは2024年11月から、区分がないと表示されない）
Google Play・Microsoft Store など	IARC（開発者は無料で取れる）
App Store	App Store Connect の質問に答える

年齢区分の考え方は「ゲーム開発の権利と規約」で詳しく扱います。

開発機材と契約（NDA）

ゲーム機向けの開発には、各社への開発者登録と承認、秘密保持契約（NDA）を含む契約、開発機（開発用に設定された専用の本体）が要ります。開発資料や SDK（開発用の道具一式）は契約の内側にあり、外に出せません。

会社と窓口	公式の案内（2026年10月時点）
任天堂（Nintendo Developer Portal）	法人に限らず個人でも登録できる。Nintendo Switch 向けの開発情報は、登録後に申請し、承認された場合にだけ見られる
ソニー（PlayStation Partners）	スタジオの情報と企画の概要で登録し、承認後に開発・パブリッシング契約（GDPA）を結ぶと、ツールや資料を使える。個人で登録できるかは登録のときに確かめる
マイクロソフト（ID@Xbox）	個人の開発者も対象で、参加は無料。18歳以上（未満は保護者）、NDA の締結、マイクロソフトが取引できる国にいることが条件。開発機は実機で試す段階で注文する

エンジンにも条件があります。Unity は各社の承認に加えて Unity Pro（または各社が出すライセンスキー）、Unreal Engine は承認された開発者であることを示してゲーム機向けの資料を申請、GameMaker はゲーム機への出力が Enterprise プランです。Godot はオープンソースのため公式のゲーム機向けの書き出しがなく、承認を受けた開発者が書き出しの部品を自作するかミドルウェアを使うか、移植会社に頼みます。

移植を楽にする作り方

ひとことで：機種ごとの違いを1か所の「窓口」に閉じ込め、ゲームの中核が機種を知らなくても動くようにしておくことです。

入力はアクションで受け取る：「ジャンプ」「決定」のような名前で受け取り、キー・ボタン・タッチへの割り当ては別の表に持ちます（Godot の Input Map、Unity の Input System など）
ボタン表示を切り替える：最後に使った入力に合わせて表示を替えます
解像度に依存しない UI：画面の端や中央を基準に配置し、16:9・16:10・縦長で崩れないかを確かめます
文字列を外に出す：コードに直書きせず表にまとめると、翻訳にも機種ごとの言い換えにも使えます（「ゲームのローカライズ」）
機種ごとの処理は1か所に：実績・クラウド保存・ストア・サインインの処理と、アプリ ID のような値を1つの窓口にまとめます
性能に余裕を持つ：いちばん弱い機器での速さとメモリを早めに測ります（「リアルタイム最適化チェックリスト」）
書き出せるかを確かめる：例えば Godot 4 の C# のプロジェクトは、Web に書き出せません（2026年10月時点の Godot 4.7 の公式ドキュメント）

筆者の「つみこめ！イカサマ魔法麻雀」では、同じビルドを体験版と本編に使い、Steam が起動時に渡すアプリ ID で見分けています。Steam と連携するライブラリに本編の ID を固定で渡していた所があり、体験版では初期化に失敗したので直しました。機種やストアごとの値を散らばらせない、という原則は移植でも同じです。

移植しやすい作りの3層の構造（どの機種でも同じゲームの中核・入力や保存などの6つの窓口・5つの機種ごとの実装）と、中核から機種へ直接つなぐ悪い例 — 図2：ゲームの中核は窓口だけを呼び、機種ごとの違いは窓口の下に閉じ込める

夕宮たいだ

窓口をひとつにしておけば、機種が増えても直す所はそこだけなんだぁ。ほら、便利でしょ？

Steam Deck と Steam Machine

ひとことで：PC 版のまま操作と画面を整え、互換性の評価を上げるのが、いちばん手軽な「別の機種」への対応です。

Steam Deck（携帯型）と Steam Machine（据え置き型）は、SteamOS の上で Windows 向けのゲームを Proton（互換の仕組み）で動かします。Steam の PC 版がそのまま動くので、別のストアへの登録や認証は要りません。代わりに、Valve による互換性の評価が4つの区分で表示されます（2026年10月時点の Steamworks のドキュメント）。

区分	意味
Verified（認証済み）	設定を変えずに全機能を使える
Playable（プレイ可能）	動くが、利用者の手作業が要ることがある
Unsupported（非対応）	Proton や機器との相性で動かない
Unknown（不明）	まだ評価されていない

認証済みの主な条件は、既定の操作設定のままコントローラーで全内容に届く、ボタン表示が使っている入力と一致する、文字入力に画面キーボードを出せる、1280×800 に対応し文字が最小 9px、既定の設定で 30fps 出る（Steam Machine は 1080p で 30fps）、などです。Steam Deck で認証済みなら、Steam Machine でも認証済みが保証されます。評価は表示だけに影響し、販売できるかどうかには関係しません（評価を申請できるのは、まだ一部のパートナーだけです）。これらの条件は、後でゲーム機に移すときの準備としてもそのまま効きます。

夕宮たいだ

ほえ〜、Steam Deck で認証済みなら、Steam Machine でも認証済みなんだぁ。最初の一歩はここからだねぇ。

Web 版（ブラウザ）の注意

ひとことで：リンク1つで遊んでもらえる一方、読み込み・音・フォント・画面の向き・ブラウザの違いに、PC 版にない注意が要ります。

ブラウザで遊べる版は、ストアの審査なしに自分のサイトで公開できます。筆者も「ブラウザで遊べる」に霧将棋などを置いています。

読み込み：最初に読む量が、遊び始めるまでの待ち時間になります。Godot が書き出す WebAssembly（ブラウザで動く実行形式）は、gzip で約4分の1に縮みます（Godot の公式ドキュメント）。大きなデータは、必要な分だけ後から読みます
音：ブラウザは一般に、クリックやタップの前は音を鳴らしません（MDN の自動再生のガイド）。最初の操作で音を始めます
フォント：Godot などで書き出したゲームは、OS のフォントで足りない文字を補えません（Godot の SystemFont は Web では使えません）。記号も含めて同梱のフォントで用意します。Windows に入っているフォントは、ゲームに同梱できません
画面の向き：スマートフォンでは縦持ちで開かれる前提にします。ゲームの側から勝手に全画面にはできません
ブラウザの違い：Godot の公式ドキュメントは、Safari の WebGL 2.0 には他のブラウザにない問題があるとしています。iPhone の Safari を含めて実機で試します
保存：ブラウザの保存領域は、空き容量が少ないときや長く開かないときに消されることがあります

公開の運用では、日付ごとのフォルダに置いて前の版を戻し用に残すと安全です。筆者はこの形で、霧将棋の版を公開から翌日未明までに5つ出しました。

夕宮たいだ

ぁぅ……PC では平気なのに、ブラウザだと音が鳴らない、記号が四角になる……ってこと、本当にあるんだよねぇ。実機で試してねぇ。

スマートフォン版の注意

ひとことで：タッチ向けの作り直しに加えて、ストアの審査と課金の規則に合わせた準備が要ります。

項目	App Store	Google Play
登録	年99ドル。個人でも登録できる	1回25ドル。個人でも登録できる
審査	アプリも更新も審査する。平均で90%が24時間以内（Apple の案内）	2023年11月13日より後に作った個人のアカウントは、一般に公開する前に、12人以上が14日以上続けて参加するクローズドテストが要る
アプリ内の販売	機能や内容の解放にはアプリ内課金を使う（ガイドライン 3.1.1。地域による例外あり）	デジタルな商品には Google Play の課金を使う（一部の国・地域に別の制度）
年齢区分	App Store Connect の質問に答える	IARC

表は2026年10月時点の公式ページ（App Review Guidelines、Google Play の支払いのポリシーほか）によります。日本では、スマートフォンのアプリストアなどの競争を促す法律が2025年12月18日に全面施行され、Apple は日本向けに、アプリ内課金以外の決済などを選べる仕組みを用意しました。条件は変わりやすいので、出す直前に各ストアの公式ページで確かめます。

作りの面では、押す部分を大きくし（Android は 48×48dp 以上を推奨）、画面の切り欠きを避けて縦持ちに組み直します。パズルなら上に盤、下に操作、のような配置です。電話や通知で中断されることも前提にして、区切りごとに保存します。

移植会社やパブリッシャーに任せる

ひとことで：移植や認証の作業を経験のある会社に任せる方法で、手間と経験を補える代わりに、費用と権利の取り決めが要ります。

移植会社（移植を専門に請け負う会社）は、ゲーム機向けの登録と開発機、認証の経験を持つことが多く、作業だけを請け負うところと、販売までまとめて引き受けるところがあります。Godot の公式サイトのゲーム機のページには、移植を手がける会社やミドルウェアの提供元が載っています。パブリッシャーが移植を手配することもあります（「インディーゲームの資金とパブリッシャー」）。任せる前には、範囲（認証や販売まで含むか）、費用の形（決まった額か売上の分配か）、ソースコードと権利、発売後の更新を誰が行うか、秘密保持の扱いを取り決めます。

AIゲーム開発での移植

ひとことで：機種の差を吸収するコードと、決まりを確かめる検査は AI に任せやすく、どの機種に何を出すかと、実機での手触りは人が決めます。

移植は、元の版という「正解」が手元で動いているので、結果を比べながら AI に任せやすい工程です。コードを書き換える手間は小さくなる一方、重心は「どの機種に、どう遊ばせて出すか」の判断と、実機での確認、契約と決まりを守る責任に移ります。作業が速いぶん出せる機種は増やせますが、機種が増えるほど更新とテストの負担も増えます。

差を吸収するコードを書かせ、決まりを関所にする

AI エージェントに任せやすいのは、入力をアクション名で受け取る層と割り当ての表、ボタン表示の切り替え、16:9・16:10・縦長に合わせた UI の配置、機種ごとの書き出しを1本にまとめるスクリプト、解像度を変えた画面の自動撮影といった作業です。元の版と同じ操作で同じ結果になるかを、画面を出さずに走らせるテスト（ヘッドレステスト）で確かめながら進められます。

機械で確かめられる決まりは、書き出しのたびに走る検査（関所）にして、違反したら止めます。筆者が作った、動画サイト内で遊べるミニゲーム版（未発表）では、公開先の決まりに「ブラウザの言語設定を読み取らない」「外部へのリンクを置かない」「初期読み込みは 30MiB 未満」がありました。言語設定の読み取りは書き出しの後に消し、消えたことをテストで検査しています。初期読み込みは実測 24.0MiB で、40MB 近い WebAssembly は gzip で約10MB にしました。

人が決めるのは「どこに出すか」と「どう遊ばせるか」

どの機種に出すか：相性・売上の見込み・費用・期間の判断と、契約
機種ごとの体験の作り直し：テレビの前で遊ぶのか、移動中に片手で遊ぶのか。操作・UI・1回の長さは変換ではなく設計です
実機での手触り：反応、押しやすさ、文字の読みやすさ、発熱
提出と公開：認証・審査への提出と、公開のボタン

霧将棋の Web 版ではオンライン対戦のサーバーまで作りましたが、筆者は「あえて出さず、Steam で開発中の将棋ゲームへ誘う」と決めました。作れることと出すべきことは別です。

落とし穴：NDA の資料と、もっともらしい作り話

NDA の資料を外部の AI サービスに貼らない：許可なく貼ったり読ませたりすると、契約違反になりえます。学習に使われない設定でも、第三者のサービスに渡すこと自体が問題になる場合があります。各社の契約と社内のルールに従い、非公開の資料は AI が読める作業フォルダに置きません。渡してよい範囲は、CLAUDE.md や AGENTS.md にも書いておきます（「CLAUDE.md 完全ガイド」「Codex AGENTS.md完全ガイド」）
機種の要件を作り話する：非公開の要件を尋ねると、それらしい数字や規則を答えることがあります。公開の資料で照合し、出典を示せない答えは推測として扱います
動くが、機種の作法に合わない：小さすぎるボタンや入力と違う表示は、テストが通っても体験として成り立ちません。目安の数値をテストにし、最後は実機で確かめます

夕宮たいだ

NDA の資料を AI に貼るの、絶対ダメだよ！便利そうでも、契約は契約なんだぁ。

筆者の実例：霧将棋の Web 版と Godot の罠

ブラウザ版の霧将棋は、開発中の将棋ゲームの中核のコードをそのまま写し、画面だけを新しく作りました。自作の将棋エンジン（C++）を WebAssembly にして、画面とは別の裏の処理（Web Worker）で動かしています（183KB・ブラウザで毎秒約100万局面）。56MB の定跡（よく知られた指し方をまとめたデータ）はブラウザに置かず、必要な部分（約0.9KB）だけを HTTP の Range（ファイルの一部だけを取り寄せる仕組み）で読みます。この Web 版は、依頼したその日に公開しました。

霧将棋の Web 版の構成。ブラウザで画面・中核のコード・将棋エンジン（C++ から WebAssembly・183KB）を動かし、サーバーの 56MB の定跡からは必要な部分（約0.9KB）だけを HTTP の Range で読む — 図3：中核のコードは将棋ゲームから写し、エンジンは WebAssembly にして裏で動かす。56MB の定跡は必要な部分だけを読む

Godot の Web 書き出しでは、筆者のブラウザ版（霧将棋・役満連荘麻雀）で次の罠を踏みました。

症状	原因	対策
▶◀✓⚠～が豆腐（□）になる	OS のフォントで補えない	予備のフォントをつなぎ、書き出しのときに字形を検査して止める
古いスマートフォンで数ゲーム遊ぶと落ちる	曲を丸ごと展開する（1曲33〜57MB）	曲はページの側で mp3 を鳴らす
音が鳴らない	実行中に音のバス（音の通り道）を足した	音の構成を実行中に変えない

スマートフォンでは、縦持ちのときに横長の画面を90度回して画面いっぱいに表示し、画像を半分にした軽量版（24.7MB→17.9MB）を読み込みます。

依頼文の例

書き方の基本は「Claude Code プロンプト設計」「Codexプロンプト設計」で解説しています。

Goal: Web 書き出しのたびに、公開先の決まりを守っているかを自動で検査する
Context: Godot 4 のプロジェクト。書き出し先は build/web/。決まりは docs/web_rules.md
  （言語設定を読まない・外部リンクなし・初期読み込み 30MiB 未満・全文字が同梱フォントにある）
Done when: 違反があれば場所を表示し、書き出しを失敗で止める。
  わざと違反を1つずつ入れて止まること、戻すと通ることを確かめた
Constraints: 公開先へのアップロードはしない（筆者が行う）

よくある失敗と対処

ひとことで：多くは「PC のまま持っていく」「機種ごとの値を散らばらせる」「決まりを後から知る」から起きます。

失敗	対処
PC の操作のまま移し、遊びにくくなる	入力をアクションで受け、機種ごとに操作を設計し直す
テレビや携帯機で文字が読めない	機種ごとの目安で確かめ、大きさを設定で変えられるようにする
ボタン表示が入力と合わない	最後に使った入力で切り替える
機種ごとの値を直書きし、別のアプリで初期化に失敗する	値と処理を1つの窓口に集める
認証や契約の条件を後から知り、作り直す	登録と資料の確認を、移植の作業より先に行う
移植版だけ直っていない不具合が残る	中核のコードを共有し、同じテストを全部の機種で走らせる