移植 (ソフトウェア)

様々な設計思想に基づいたコンピュータが、様々なメーカーから発売されており、またそれらのコンピュータ上で動作するプログラムを記述するためのプログラミング言語も多岐に渡っている。移植性は、OS自体の違いというよりも、システムコールやコマンドなどの違い（例えばLinux、GNU Hurd、FreeBSD、macOS、Plan 9などのPOSIX、およびそれ以外）、CPUおよび命令セット（機械語）の違い (ARM, x86, x64)、拡張命令、ビット長（8ビット、16ビット、32ビット、64ビット、128ビット、256ビットなど）、ネットワークアダプターやストレージ、グラフィックスカード（GPU）やサウンドカードといった周辺機器のデバイスドライバサポート状況、そして利用できるライブラリの違いに左右される。例えば、同じPOSIXのGNU/Linux, FreeBSD, macOS間の移植性は比較的高い。またWin32 APIを備えるMicrosoft Windowsシリーズ間の移植性も比較的高い。

互換性のあるコンピュータ上では、OSに用意されたAPIや、そのAPI経由で利用されているデバイスドライバの働きによって、ハードウェアのベンダーや機種の違いが隠蔽され、ハードウェア仕様の差異やデバイス構成の違いなどは気にせずとも同じアプリケーションソフトウェアの実行ファイル（バイナリ）が利用できる。アプリケーションソフトウェアは、OSが提供する標準化・抽象化された環境上で動作する。

しかし、WindowsとMacシリーズなどのように、互換性のないコンピュータ上では、一部のソフトウェアを除き、同じ実行バイナリは動作しない。これらはOS側で提供している環境が異なるためである。また、OSによってサポートされる第一級（ファーストクラス）のプログラミング言語が異なることもあり、特にウィジェット・ツールキットを利用するGUIアプリケーションの移植に際して、それぞれの言語を使用してソフトウェアの一部またはすべてを書き直さなければならないこともある。例えばMac/iOSではObjective-C/Swiftが、AndroidではJava/Kotlinが、WindowsではC++/C#/VB.NETが主要な第一級言語としてサポートされ、公式のウィジェット・ツールキットはそれぞれの第一級言語から利用することを想定されている。

プラットフォームごとにソフトウェアを記述するのではなく、クロスプラットフォームなアプリケーションフレームワークを利用して、移植性やメンテナンス性を高める手法が採られることも多い。また、移植性を高めるために、プラットフォームやプロセッサ命令セットを抽象化した仮想マシンや中間表現が利用されることもある。オラクル（旧サン・マイクロシステムズ）のJavaは、プラットフォームに依存しない仮想的な実行環境 (Java Runtime Environment, JRE) を定義し、その仮想環境上で動作するJava仮想マシン (Java VM) とクロスプラットフォームなクラスライブラリ (Java API) を用意することで、JREをサポートする環境であれば一度書いたアプリケーションプログラムを変更することなくそのまま実行できるエコシステムを構築し、一定の成功を収めている。

OpenGLやOpenCLなどのように、標準化されたAPIのオープン規格も存在する。これらのAPIをサポートするプラットフォーム間では、ソフトウェアの移植がしやすくなるが、実際のAPIの実装であるデバイスドライバの品質や規格への準拠レベルは、個々のベンダーによってまちまちである。

旧来、特に動作環境が異なるコンピュータの多くでは、同じ動作・作業をさせるために、全く別々にプログラムを作成しなければならない場合もあり、ハードウェア構成の差異を吸収してくれるOSやデバイスドライバが無かった時代には、たとえ同一メーカーのコンピュータであっても、機種が異なる場合はプログラムの大半を作り直す作業が必要とされることがあった。

このため、特にパーソナルコンピュータ (PC) が普及し始めていた1980年代においては、各ソフトウェアメーカーとも、採算性の上でシェアが狭い機種など、売上が見込めない機種にはソフトウェアの移植を行わないケースも見られた。その一方で、採算さえ取れそうなら、非常に性能の低いPC向けにでさえ、ソフトウェアメーカーは多大なプログラミングテクニックと試行錯誤という労力を費やしてでも、移植ソフトウェアを作り続けた。その結果、日本のPC市場は1980年代末には8ビット御三家と呼ばれる三強と、様々なメーカーからの互換性のあるMSXシリーズによる寡占化傾向が定着していた。

一方情報工学分野でも、様々なコンピュータメーカーから、多種多様な大型・小型を問わず1970年代以降、様々なコンピュータが発売・供給されたが、プラットフォームごとに操作方法が大きく違うことに辟易する利用者も多かった^[要出典]。そのような中、マルチユーザー・マルチタスクの思想から生まれたUNIXは広く産官学分野に受け入れられ、様々なコンピュータ上で動作するUNIXの流れを汲むOSが移植された。

また、家庭にあるPC上でも同じOSを使いたいというユーザーもあらわれ、LinuxやFreeBSD等の、PC/AT互換機上で動作するものも開発されてきた。特にLinuxに関しては、家庭用ゲーム機や携帯機器あるいは過去のコンピュータハードウェア等で動作させることが、一部のマニア間で腕試しに競われた結果、Xboxやプレイステーション上でも動作する環境が開発されている^[要出典]。

2010年代には、いずれのプラットフォームに対しても同時に同質のアプリケーションを展開することは一般的になっている。ただし限界もあり、たとえばPC向けのアプリケーションをスマートフォンやタブレットデバイス向けにそのまま移植することは、解像度や操作体系（マウスおよびキーボードあるいはタッチスクリーン）などの違いから困難あるいは不可能だが、PCおよびタブレットなどの異なるデバイス間で、Windowsアプリケーションを移植しやすくする開発・実行環境として、Microsoft Windows 8以降にはWindowsランタイムと呼ばれるAPIが搭載されており、Microsoft Windows 8.1およびMicrosoft Windows 10では移植性に関する改善も続けられている^[1][2]。

かつて、コンピュータゲームのゲームソフトは通常1種類のゲーム機（ゲームコンソール）にのみ独占的に対応して開発・販売されることが多く、移植といえば主に（高性能な）アーケード機から（低性能な）家庭用ゲーム機への移植を指すことがほとんどだった。しかし、Xbox 360/PlayStation 3/Wiiといった高性能なコンソールが出現する頃には、最初から複数のプラットフォームで製品販売を展開することを視野に入れて開発されることも多くなっている。他機種に同一内容のゲームソフトを提供するためにはソフトウェア開発メーカー、または外注ないしライセンス提供を受けた別のソフトウェア開発企業（サードパーティー）による移植作業が必要である。移植のパターンは大きく分けて以下の4通り存在する。

1. 過去のゲームソフトを現行機種向けに移植する場合（グラフィックスやサウンドの刷新といったリメイクが行なわれることもある）
2. 比較的最近のソフトをより普及している現行機へと移植する場合
3. アーケードゲームハードから家庭用ゲーム機へと移植する場合
4. 同時期に普及する複数の家庭用ゲーム機へ移植することを、始めから前提として作られる場合

複数機種への移植はマルチプラットフォーム対応（マルチプラットフォーム展開）とも呼ばれ、場合によっては同時期に発売するために並行して移植作業が行なわれるケースもある。

かつて8ビット御三家のように主要なプラットフォームが並行進化の形で複数存在し市場を争っていた時代には、メーカーの開発陣に余力のある場合に、例えばDAIVAのように、新製品のソフトウェアを複数機種向けに並行して開発して、ほぼ同時発売することもしばしば行われた。また、余り規模が大きくない企業でもレリクスのように、1機種向けに先行販売して、雪崩式に次機種向けに移植作業を続行、次々に多機種展開するメーカーも見られた。またテグザーなどのように、外注やライセンス提供で結果的に多機種展開したケースも見られる。

ゲームの移植で独特の問題となるのは操作デバイスである。コントローラのボタン数やその配置、アナログ的入力の有無などは機種ごとに異なるので、違和感の無い操作を再現するために移植先にあわせたアレンジや調整が必要となる場合がある。各機種間のフレームレート、画面解像度の違いも大きな問題となりうる。このような移植対象のゲーム機（コンシューマーゲーム）の性能や仕様上の違いによるゲーム内容の変更といったことも、かつては頻繁に行なわれていた。

たとえば、8ビットパソコンの時代にはアーケード版『ゼビウス』の移植作品『タイニーゼビウス』のように、ゲームルールは変更せずにゲームの映像面を大幅に省略したり、あるいはファミリーコンピュータ用『グラディウス』のように、操作機器（入力機器）の違いにより1つのボタンに複数の機能を割り当てるよう仕様変更されたり、といったケースが挙げられる。こういったダウングレード的改変はPCおよびコンシューマーゲーム機の機能がアーケードゲーム機に及ばない時代にはしばしば見られた。2000年代頃からは、1980 - 1990年代の古いゲームを最新機種に移植する場合、逆に映像や音楽のアップグレードを図る場合もある。

また移植に際してバグ（裏技として認識されるプレイヤーにとって好都合なものも含む）の修正や、ゲームバランスの調整、要素の追加などが行われる場合も多い。たとえば『アトミックロボキッド』では、アーケードゲーム版が「敵弾やボスとの接触が即ミス、残機が無くなればゲームオーバー」だったものが、PCエンジンへのアレンジ移植版『アトミックロボキッドスペシャル』はライフ制に変更、「敵弾やボスとの接触でライフ減少、ライフ切れでゲームオーバー」になった。このようなケースでは、ゲームルールの改変などもあって、原作を元に別の内容の作品を作り上げるリメイクとの区別が曖昧である。この他発売当時はあまり問題視されていなかった表現が、後年になって何らかの問題があると判断された場合、移植の際に問題の表現を修正することがある。

プレイステーションなどの世代からハードウェアの性能の向上に伴って、各メーカーは他機種からの完全移植を目指そうとしているが、メーカーによって移植度はまちまちであり、中には致命的なバグを含んだ移植ソフトや、あるいは実質リメイクであるものも存在する。またロムカセットやCD-ROMなど記録媒体の情報量増加に伴い、主となるソフトウェアはリメイク物ではあるが、オリジナルモードと称して原作の忠実な移植版を含んでいるソフトウェアもまま見受けられ、『スペースインベーダー』や『パックマン』など往年の有名ゲームでは複数モードを持つソフトウェアもみられる。

厳密な意味での移植に関しては、特にアーケードゲームの移植を待ち望んでいるユーザーらは、この移植度に厳しい傾向も見られる。たとえばアーケードゲームでやり込みプレイに興じたプレーヤーにとっては、入力機器の操作感の違いもあるが、アーケードゲームで鍛えたテクニックが使えないと不評を漏らしたり、アーケード版でバグないし設定ミスなどの形で存在していた（さして重要視されないような）要素が移植に際して修正されていたりすると、その再現性の違いに不評を述べたりするようなケースである。こういった傾向はゲーマーの中でもコアゲーマー（所定作品に思い入れの強いゲーム愛好家）に見られる要素である。一方で、バグの多いゲームの移植や、操作性の大きく異なるハードウェアに向けての移植（具体例を挙げると、WindowsからWii、iアプリからiPhone・iPod touchなど）のように、何らかの改善が期待される状況で何らの改善も行われていないものについて、「ベタ移植」と蔑まれるケースもあり、難しい^[要出典]。

ただ、コンピュータゲームプログラムの開発が次第に大規模になっていく過程で、異なるプラットフォームで同じように動作する環境（フレームワーク）をあらかじめ構築し、その上でゲームを動作させようという動きもある。ゲームエンジンと呼ばれる共通プログラムは、ゲームソフト開発の手間を軽減するために利用されているが、その一方でよく利用されるゲームエンジンが様々なプラットフォーム向けに移植されることで、そのゲームエンジンを利用するゲームソフトの移植に必要な労力やコストの低減にも役立てられている。

PlayStation 4やXbox Oneでは、x86ベースのAMD APUが採用されたことから、PCゲームの相互移植がしやすくなっている。

• 移植性
• 仮想マシン/エミュレータ - 個々のソフトウェアではなく、動作環境全体の移植である
• リメイク