パッチ（コンピューティング）

パッチは、プログラムやファイルなどの既存のソフトウェアリソースを変更するために使用されることを目的としたデータであり、多くの場合、バグやセキュリティの脆弱性を修正します。^{[1] [2]}パッチは、機能性、使いやすさ、またはパフォーマンスを向上させるために作成される場合があります。パッチは通常、ベンダーが提供するソフトウェアを更新するためにベンダーによって提供されます。パッチは手動で作成することもできますが、一般的には、リソースの2つのバージョンを比較し、一方を他方に変換するために使用できるデータを生成するツールを使用して作成されます。

通常、パッチは変更対象のリソースの特定のバージョンに適用する必要がありますが、例外もあります。一部のパッチ適用ツールは、複数のバージョンをサポートしている場合でも、既存のリソースのバージョンを検出し、適切なパッチを適用できます。リリースされるパッチが増えると、その累積サイズが大幅に増加し、リソース自体のサイズを超えることもあります。これを管理するために、サポートされるバージョンの数を制限したり、代わりにリソースの完全なコピーを提供したりすることがあります。

パッチを使用すると、ソースコードが利用できない場合でも、コンパイルされた(マシン言語) プログラムを変更することができます。これには、コンパイルされたコードの内部動作を完全に理解する必要がありますが、ソース コードにアクセスできない場合は困難です。また、パッチを使用すると、ソースから再構築せずにプログラムに変更を加えることもできます。小さな変更の場合は、完全なリソースを配布するよりも、パッチを配布する方が経済的です。

多くの場合、パッチは問題を修正することを目的としていますが、設計が不十分なパッチは新しい問題を引き起こす可能性があります (ソフトウェアの回帰を参照)。場合によっては、更新プログラムによって意図的に機能が破壊されたり、デバイスが無効になったりすることがあります。たとえば、更新プログラムの提供者がライセンスを失っているコンポーネントが削除されることがあります。パッチ管理はライフサイクル管理の一部であり、特定の時間にどのシステムにどのパッチを適用するかという戦略と計画を使用するプロセスです。通常、パッチはプログラムされた制御によってコンピューターのストレージに適用され、永続的になります。場合によっては、プログラマーがデバッガーなどのツールを使用してコンピューターのメモリにパッチを適用し、リソースがストレージから再ロードされたときに変更が失われることがあります。

プロプライエタリ ソフトウェアのパッチは、通常、ソース コードではなく実行可能ファイルとして配布されます。これらのファイルを実行すると、ディスク上の対象プログラムへのパッチ コードのインストールを管理するプログラムがメモリにロードされます。

他のソフトウェアのパッチは、通常、パッチ コードを含むデータ ファイルとして配布されます。これらは、インストールを実行するパッチユーティリティ プログラムによって読み取られます。このユーティリティは、通常、新しいパッチ コードを表すバイトでそのバイトを上書きすることによって、ターゲット プログラムの実行可能ファイル (プログラムのマシン コード) を変更します。新しいコードが古いコードが占めるスペース (バイト数) に収まる場合は、古いコードに直接上書きすることで配置できます。これは、インライン パッチと呼ばれます。新しいコードが古いコードより大きい場合は、パッチ ユーティリティは、パッチを適用するターゲット プログラムのオブジェクト ファイルに、新しいコードを含むロード レコードを追加します。パッチを適用したプログラムを実行すると、古いコード内の新しいコードが必要な場所に、分岐命令 (ジャンプまたは呼び出し) がパッチされた新しいコードに実行が指示されます。 Radio Shack TRS-80などの初期の 8 ビット マイクロコンピュータでは、オペレーティング システムに PATCH/CMD ユーティリティが含まれており、テキスト ファイルからパッチ データを受け取り、対象プログラムの実行可能バイナリ ファイルに修正を適用します。

パッチ コードは、実行時に実行されるメモリ内に場所を確保する必要があります。インライン パッチは難しくありませんが、追加のメモリ領域が必要な場合は、プログラマーが即興で対応する必要があります。当然、パッチ プログラマーがパッチ対象のコードを最初に作成した人であれば、これは簡単です。熟練したプログラマーは、最終的な反復を作成するときに未使用のままにしておき、後で拡張できるようにメモリを予約することで、このニーズに事前に備えます。元の実装に関与していない他のプログラマーが、後で変更を組み込もうとする場合は、必要な追加バイト用の領域を見つけるか、作成する必要があります。これに対して最も幸運な状況は、パッチ対象のルーチンが個別のモジュールである場合です。この場合、パッチ プログラマーは、モジュールが占める領域を他のシステム コンポーネントに通知するポインターまたは長さインジケータを調整するだけで済みます。その後、拡張したパッチ コードをこのメモリ領域に自由に配置できます。パッチ対象のルーチンが個別のメモリ モジュールとして存在しない場合は、プログラマーはルーチンを縮小して、拡張したパッチ コードに十分な領域を確保する方法を見つける必要があります。一般的な戦術としては、より効率的な命令シーケンスを見つけることによって（またはより効率的なアルゴリズムで再設計することによって）コードを短縮すること、メッセージ文字列やその他のデータ領域を圧縮すること、プログラム機能を大容量ストレージ（ディスク オーバーレイなど）に外部化すること、またはパッチでインストールされる変更よりも重要度が低いと判断されるプログラム機能を削除することなどがあります。

CP/Mの DDT やMS-DOSの DEBUG デバッガーなどのシステム デバッグ ユーティリティを使用して、メモリ内の小さなマシン コード パッチを手動で適用できます。インタープリタ型BASICで作業するプログラマーは、システム サービス ルーチンまたはインタープリタ自体の機能を変更するために、POKE コマンドをよく使用していました。

パッチは、ソース コードの変更という形で流通することもあります。この場合、パッチは通常、2 つのソース コード ファイル間のテキストの相違 (「diff 」と呼ばれる) で構成されます。このタイプのパッチは、一般にオープン ソース ソフトウェア プロジェクトから生まれます。このような場合、開発者は、ユーザーが新しいファイルまたは変更されたファイルを自分でコンパイルすることを期待します。

「パッチ」という言葉には小さな修正という意味合いがあるため、大きな修正には異なる名称が使用されることがあります。かさばるパッチやプログラムを大幅に変更するパッチは、「サービス パック」または「ソフトウェア アップデート」として流通することがあります。Microsoft Windows NTおよびその後継製品 ( Windows 2000、Windows XP、Windows Vista、Windows 7など) では、「サービス パック」という用語が使用されています。^[3]歴史的に、IBM はこれらのアップデートを指すのに「FixPaks」および「修正サービス ディスケット」という用語を使用していました。^[4]

歴史的に、ソフトウェア供給者はパッチを紙テープまたはパンチカードで配布し、受け取った人が元のテープ（またはデッキ）の指定された部分を切り取り、交換セグメントにパッチを当てる（そのためこの名前が付けられている）ことを期待していた。その後、パッチの配布には磁気テープが使用されるようになった。その後、リムーバブルディスクドライブが発明されると、パッチはソフトウェア開発者からディスク経由で、後にはCD-ROM経由で郵送されるようになった。インターネットアクセスが広く利用できるようになったことで、開発者のWeb サイトからパッチをダウンロードしたり、自動ソフトウェア更新を通じてパッチをエンドユーザーが利用できるようになることが多くなった。Apple のMac OS 9と Microsoft のWindows MEから、PC オペレーティングシステムはインターネット経由で自動ソフトウェア更新を取得する機能を獲得した。

コンピュータ プログラムは、多くの場合、パッチを調整してターゲット プログラムを更新できます。自動化により、エンド ユーザーの作業が簡素化されます。エンド ユーザーは更新プログラムを実行するだけでよく、その後はプログラムがターゲットの更新を完全に正しく実行します。Microsoft Windows NTおよびその後継製品、および多くの商用ソフトウェア製品のサービス パックでは、このような自動化戦略が採用されています。

一部のプログラムは、ユーザーによる介入をほとんどまたはまったく必要とせずに、インターネット経由で自動的に更新できます。サーバーソフトウェアやオペレーティング システムのメンテナンスは、多くの場合この方法で行われます。システム管理者が多数のコンピューターを管理する場合、このような自動化によって一貫性を保つことができます。セキュリティ パッチの適用も、一般的にこの方法で行われます。

大容量のストレージ メディアとより広いインターネット帯域幅の出現により、特に小規模なプログラムの場合、既存のファイルを変更するのではなく、ファイル全体 (またはプログラム ファイル全体) を置き換えることが一般的になりました。

パッチのサイズは、数バイトから数百メガバイトまでさまざまです。したがって、変更内容が大きければ大きいほど、サイズも大きくなります。ただし、これは、パッチにファイル全体が含まれているか、変更された部分のみが含まれているかによっても異なります。特に、変更によってグラフィックやサウンド ファイルなどのプログラム以外のデータが追加または置き換えられる場合、パッチのサイズは非常に大きくなる可能性があります。このような状況は、コンピューター ゲームのパッチ適用でよく発生します。ソフトウェアの初期インストールと比較すると、パッチの適用には通常、それほど時間がかかりません。

オペレーティングシステムやコンピュータサーバソフトウェアの場合、パッチはセキュリティホールを修正するという特に重要な役割を担っています。重要なパッチの中には、ドライバの問題を伴うものもあります。^[5] パッチを適用するには、事前に他のパッチを適用しておくことや、複数の独立したソフトウェアコンポーネントを事前にまたは同時に更新しておくことが必要になる場合があります。更新を容易にするために、オペレーティングシステムでは自動または半自動の更新機能を備えていることがよくあります。完全に自動の更新は、前述の不具合もあって企業のコンピューティング環境では広く普及していませんが、管理者はソフトウェア会社がコンピュータを無制限に制御できるようになることを恐れているためでもあります。^[要出典] パッケージ管理システムは、さまざまなレベルのパッチ自動化を提供できます。

完全に自動的な更新の使用は、Microsoft Windows が^{[いつ? ]}それらのサポートを追加し、Windows XP の Service Pack 2 (2004 年に利用可能) でそれらがデフォルトで有効になったという^事実により、消費者市場ではるかに広まりました [^要出典]。慎重なユーザー、特にシステム管理者は、修正の安定性を確認できるまでパッチの適用を延期する傾向があります。Microsoft (W)SUS はこれをサポートしています。大規模なパッチや重要な変更の場合、ディストリビューターはベータ テストとして、パッチの提供を資格のある開発者に限定することがよくあります。

ファームウェアにパッチを適用することは、以前のバージョンとの差分のみを適用するのではなく、完全に新しいファームウェア イメージのプロビジョニングを伴うことが多いため、特別な課題を伴います。パッチは通常、バイナリ データ形式のファームウェア イメージと、以前のバージョンを新しいバージョンに置き換えるサプライヤ提供の特別なプログラムで構成されます。マザーボードの BIOS更新は、一般的なファームウェア パッチの例です。更新中に停電などの予期しないエラーや中断が発生すると、マザーボードが使用できなくなる可能性があります。マザーボードの製造元は、重大な損傷を防ぐために安全策を講じることができます。たとえば、更新手順でファームウェアのバックアップを作成して保持し、プライマリ コピーが破損していると判断された場合に使用します (通常はCRCなどのチェックサムを使用)。

ビデオゲームは、他のソフトウェアと同様に、最初のリリース後に互換性の問題を修正するためのパッチを受け取りますが、ゲームのルールやアルゴリズムを変更するために適用される場合もあります。これらのパッチは、マルチプレイヤーゲームエクスペリエンスで他のプレイヤーに対して不当な優位性を得るために使用できるエクスプロイトが発見されたことがきっかけとなる場合があります。追加機能やゲームプレイの調整が頻繁に追加されます。これらの種類のパッチは、マルチプレイヤー機能を備えたファーストパーソンシューティングゲームでよく見られます。また、通常は非常に複雑で大量のコンテンツを含むMMORPGでは、最初のリリース後のパッチに大きく依存することがほとんどで、パッチによってプレイヤーが利用できる新しいコンテンツや機能が追加されることがあります。エクスプロイトによって、MMORPG のすべてのプレイヤーのバランスと公平性が短期間で深刻に損なわれる可能性があるため、重要なパッチと修正を適用するために、MMORPG のサーバーが突然停止されることがあります。

企業はバグがあることを承知でゲームをリリースすることがある。Computer Gaming WorldのScorpia は1994年に「パッチやアップグレードで済むことを知りながら粗悪な製品をリリースし、顧客を「有料テスター」にする企業 (数え切れないほど多い)」を非難した。^[6]

頻繁に使用またはメンテナンスされるプログラムのライブラリやソース コードの一部に関する問題を修正するために、パッチが必須になる場合があります。これは、非常に大規模なソフトウェア プロジェクトでよく発生しますが、小規模な開発ではほとんど発生しません。

オープンソース プロジェクトでは、通常、作者はパッチを受け取ったり、多くの人が特定の問題を修正したり、プロジェクトのロケール外のローカル言語のサポートなどの特定の機能を追加したりするパッチを公開したりします。Linux カーネル(完全なソースコードを公開していることで有名) の初期開発の例では、オリジナルの作者であるLinus Torvalds は、多くのプログラマーから、元のバージョンに適用する 数十万のパッチを受け取りました。

Apache HTTP Server は、もともとBrian Behlendorf がNCSA HTTPd を改良するために集めたパッチから発展したため、パッチの集合 ( 「パッチだらけのサーバー」 ) であることを示す名前になっています。プロジェクトの公式サイトの FAQ には、「Apache」という名前はアメリカ先住民のApache族に敬意を表して選ばれたと書かれています。ただし、「パッチだらけのサーバー」という説明は、当初プロジェクトの Web サイトで行われました。^[7]

ホットフィックスまたはクイック フィックス エンジニアリング アップデート (QFE アップデート) は、ソフトウェア製品の問題 (つまり、ソフトウェアのバグ) に対処するために使用される情報 (多くの場合、1 つ以上のファイルの形式) を含む単一の累積パッケージです。通常、ホットフィックスは特定の顧客の状況に対処するために作成されます。Microsoftはかつてこの用語を使用していましたが、現在は新しい用語である一般配布リリース (GDR) と限定配布リリース (LDR) を使用しています。ただし、 Blizzard Entertainment は、ホットフィックスを「通常のコンテンツ パッチまで延期できないほど重要と判断されたゲームへの変更」と定義しています。

ポイント リリースはソフトウェア プロジェクトのマイナー リリースであり、特に重要な機能を追加するのではなく、バグを修正したり、小さなクリーンアップを行うことを目的としたリリースです。多くの場合、1 回のメジャー リリースまたはマイナー リリースでは修正できないほど多くのバグがあるため、ポイント リリースが必要になります。

プログラム一時修正または製品一時修正 (PTF) は、日付によって異なりますが、単一のバグ修正、または顧客がインストールできる形式で配布される一連の修正を指すIBM の標準用語です。PTF は「ZAP」と呼ばれることもあります。 ^[8] 顧客は、この頭字語を冗談交じりに永久一時修正、またはより実際的にはおそらくこの修正と説明することがあります。これは、パッチによって問題が解決した場合、PTF をオペレーティング システムの永続的な一部にすることができるためです。

セキュリティ パッチは、脆弱性によって説明される弱点を修正するために資産に適用される変更です。この修正アクションにより、攻撃の成功を防ぎ、脅威が資産内の特定の脆弱性を悪用する能力を排除または軽減します。パッチ管理は、脆弱性管理 (脆弱性の特定、分類、修正、軽減を繰り返す作業) の一部です。

セキュリティ パッチは、ソフトウェアのセキュリティ脆弱性を修正する主な方法です。現在、Microsoft はセキュリティ パッチを月に 1 回 (「パッチ チューズデー」) リリースしており、他のオペレーティング システムやソフトウェア プロジェクトには、脆弱性の発表後できるだけ早く最も信頼性の高いソフトウェア パッチをリリースすることに専念するセキュリティ チームがあります。セキュリティ パッチは、責任ある開示と密接に結びついています。

これらのセキュリティ パッチは、ビジネス プロセスが影響を受けないようにするために重要です。2017 年、企業はWannaCryと呼ばれるランサムウェアの攻撃を受けました。これは、 Microsoft Windowsの特定のバージョンでファイルを暗号化し、BitCoin で身代金を要求するものです。これに対応して、Microsoft はランサムウェアの実行を停止するパッチをリリースしました。

サービス パック (SP) または機能パック (FP) は、単一のインストール可能なパッケージの形式で提供されるソフトウェア プログラムに対する更新、修正、または機能強化のコレクションで構成されます。企業では、特定のプログラムに対する個別のパッチの数が一定 (任意) の制限に達したとき、またはユーザーのフィードバックやBugzillaなどのバグ追跡に基づいて、ソフトウェア リリースが安定し、残っている問題の数が少ないことが判明したときに、サービス パックをリリースすることがよくあります。オフィス スイート、オペレーティング システム、データベース ソフトウェア、ネットワーク管理などの大規模なソフトウェア アプリケーションでは、製品のリリース後 1 ～ 2 年以内にサービス パックが発行されることは珍しくありません。サービス パックのインストールは、多数の個別のパッチをインストールするよりも簡単でエラーも少なく、サービス パックが一般的なネットワーク経由で複数のコンピューターを更新する場合はなおさらです。

非公式パッチとは、元の開発者ではなく第三者が作成したプログラムのパッチです。通常のパッチと同様に、バグや欠陥を軽減します。例としては、ソフトウェア制作者による公式パッチ自体に時間がかかりすぎる場合に、セキュリティ専門家がセキュリティ修正を行うことがあります。^{[9] [ 10]その他の例としては、サポートが終了した}ビデオゲームのゲームコミュニティが作成した非公式パッチがあります。^{[11] [12]}

モンキー パッチとは、プログラムをローカルで拡張または変更する (プログラムの実行中のインスタンスにのみ影響する) ことを意味します。

ホットパッチは、ライブパッチや動的ソフトウェア更新とも呼ばれ、システムや関連プログラムをシャットダウンして再起動せずにパッチを適用することです。これにより、システムまたはプログラムによって提供されるサービスが利用できなくなる問題に対処します。^[13] この方法を使用すると、システムを停止せずにLinuxカーネルを更新できます。 ^{[14] [15]} この方法で適用できるパッチは、ホットパッチまたはライブパッチと呼ばれます。これは、モバイルアプリの分野では一般的な方法になりつつあります。^[16] Rollout.ioなどの企業は、メソッドスウィズリングを使用してiOSエコシステムにホットパッチを配信しています。^[17] iOSアプリにホットパッチを適用する別の方法は、JSPatchです。^[18]

クラウドプロバイダーは、基盤となるインフラストラクチャを更新する際に顧客のダウンタイムを回避するためにホットパッチを使用することが多い。^[19]

コンピューティングにおいて、スリップストリームとは、パッチ（サービスパックを含む）を元のアプリのインストールファイルに統合し、更新されたアプリを直接インストールできるようにする行為である。^{[20] [21]}

スリップストリームの性質上、初期には時間と労力がかかりますが、長期的には多くの時間 (ひいてはコスト) を節約できます。これは、多数のコンピューターを管理する管理者にとって特に重要です。各コンピューターにオペレーティング システムをインストールする一般的な方法は、元のメディアを使用して、インストールが完了した後に各コンピューターを更新することです。この方法は、より最新の (スリップストリームされた) ソースから開始し、スリップストリームされたソースに含まれていないいくつかの更新をダウンロードしてインストールする必要があるよりも、はるかに時間がかかります。

ただし、すべてのパッチをこの方法で適用できるわけではなく、特定のパッチが後の問題の原因であることが判明した場合、元の非スリップストリーム インストール ソースを使用しないと、そのパッチを削除できないという欠点があります。

ソフトウェア更新システムでは、ユーザーとソフトウェア開発者が更新を管理できます。2017年のPetyaサイバーパンデミックでは、金融ソフトウェア「MeDoc」の更新システムが侵害され、更新を介してマルウェアが拡散したと言われています。 ^{[22] [23]} Torブログで、サイバーセキュリティの専門家であるマイク・ペリーは、決定論的な分散ビルドが、ソフトウェア開発およびビルドプロセスを攻撃し、単一の公式署名された即時更新で数百万台のマシンに感染するマルウェアから身を守る唯一の方法である可能性が高いと述べています。 ^[24]更新マネージャーを使用すると、セキュリティ更新を迅速かつ広範囲に適用することもできます。SynapticなどのLinuxの更新マネージャーを使用すると、ユーザーはマシンにインストールされているすべてのソフトウェアを更新できます。Synapticなどのアプリケーションは、マルウェアに対する忠実性を確保するために、暗号化チェックサムを使用してソース/ローカルファイルを適用する前に検証します。^{[25] [26]}

ハッカーによっては、正当なソフトウェア更新チャネルを侵害し、悪意のあるコードを挿入する可能性がある。 ^[27]

• ソフトウェアリリースライフサイクル
• ソフトウェアメンテナンス
• バックポート
• ドリブルウェア
• パッチ (Unix)
• 移植
• 脆弱性データベース
• デルタエンコーディング
• SMP/E
• 自動バグ修正
• シャブリク・テクノロジーズ
• ホワイトハット（コンピュータセキュリティ）

• パッチのJargonファイルエントリ
• セキュリティパッチを扱った詳細な修士論文
• 公式 Linux カーネル パッチ形式
• 0-Day Patch – ベンダーのセキュリティ パフォーマンスの暴露。2014 年 1 月 31 日にWayback Machineにアーカイブされました。Microsoft と Apple のパッチ パフォーマンスを比較する指標。