プラグイン

プラグイン (plug-in)

コンセントとプラグで電力を供給する機器。
電子機器において機能拡張、仕様変更をおこなうために規格化された差し替え可能なモジュール。
アプリケーションソフトウェアの機能を拡張するために追加することのできるプログラムモジュールの一種。本稿で記載する。

概説[編集]

通常、コンピュータ上で動作するプログラムは、中心となるプログラムコードがサブルーチンを呼び出して処理を進める形で構成される。処理の基本の流れは同じでも、処理内容の詳細が異なるアプリケーションコードを作る場合には、いくつかのサブルーチンを入れ替えることにより実現する。例えば、「ビットマップ画像ファイルを読み込んで画面に表示をする」というアプリケーションの場合、ファイル読み込みのサブルーチンを差し替えることにより、「PNGを読み込んで画面に表示をする」プログラムや「JPEGを読み込んで画面に表示をする」プログラムなどのバリエーションを作ることができる。逆の操作すなわちファイル保存に関しても同様である。

多くのソフトウェアでは、この差し替え可能な部分のサブルーチンの呼び出し手順（インターフェイス）は公開されておらず、アプリケーション・コードを開発した者だけが差し替え作業ができるようになっている。しかし、上記の画像ファイルのフォーマットの例のように、必要とされる全てのサブルーチンを大元の開発者が用意できるとは限らない場合がしばしば発生する。このような場合、サブルーチンの呼び出し手順を規格化して公開・公表し、さらにサブルーチンの差し替え方法を提供すれば、大元の開発者以外の第三者もアプリケーションの機能を変更・拡張できるようになる。

このようにアプリケーションコードの一部分が誰でも差し替え可能になっている状態をプラグ可能（pluggable）と呼び、外部から注入されるプログラムコードおよびそのモジュールをプラグインと呼ぶ。

プラグインの機構を実現するためには、次の点を外部公開仕様として明確に規格化しなければいけない。

サブルーチンに与える（入力）パラメータのフォーマットと意味の定義
サブルーチンから受け取る（出力）データのフォーマットと意味の定義
サブルーチンを呼び出す手順（サブルーチンの名前や呼び出し規約なども含む）
サブルーチンが呼び出されるタイミング（実行されるスレッドなども含む）
モジュールを配置する場所（ディレクトリ）

また、プラグインとなるサブルーチンのコードを開発しやすいように、プラグイン開発用のライブラリ（フレームワーク）が大元のホストアプリケーション開発者から提供されることが多い。

コンパイラを用いて作られたアプリケーションコードでは、原則としてサブルーチンの実行メモリアドレス（相対アドレス）はコンパイル時に決定されてしまうため、サブルーチンの差し替えをする度に再度コンパイルが必要となる。プラグインの場合、ダイナミックリンクライブラリと呼ばれる機構を使って、アドレスをOSのローダーに決定させることによりこの問題を回避する。また、ヒープ上に動的メモリ確保されるオブジェクトは、ランタイムライブラリにバイナリ互換性がない限り、モジュール境界を越えて確保・解放することができないが^[1]^[2]、対となる動的なメモリ確保と解放の処理をプラグインのモジュール内に閉じ込めてしまうことで、プラグインの開発者とアプリケーションの開発者が異なるコンパイラや異なるコンパイルオプション、異なるプログラミング言語を使用することも可能である。

ダイナミックリンクライブラリは、WindowsではDLL形式が、macOSやLinuxなどのUNIX / Unix系 OSではso形式が用いられることが多い。これは、OSの開発者が規格化したサブルーチン呼び出し手順であり、OSがその呼び出しを実現する標準APIなどを提供しているので、プラグインを開発する者もプラグイン機構を開発する者も簡単にかつ安定して利用できるからである。プラグインを実装する側では特定の名前と呼び出し規約を持つサブルーチンを実装してシンボルをエクスポートしておき、プラグインを利用するホストアプリケーション側では実行時にモジュールをロードして名前の文字列をもとにサブルーチンのアドレスを探索し、見つかった場合はそのサブルーチンのアドレスを利用して呼び出す、というダイナミックバインディングの技術が用いられる。

Windowsではプラグインの実現にCOM/ActiveXテクノロジーが用いられていることもある。注入されるコードは単純なサブルーチンではなく、オブジェクト指向のインターフェイスを実装したクラスとして実現される。.NET Frameworkではプラグイン機構の実現を容易にするためのフレームワークとして、バージョン4.0でManaged Extensibility Framework（英語版）が追加された。

なお、スクリプト言語の処理系をアプリケーションに組み込んでおくことで、プラグインと類似の機構を実現することもできる。

セキュリティ[編集]

アプリケーションの外部からコードを読み込んで実行することで、サードパーティ製のプラグインを利用できるようにすると、コードインジェクションやコードの改竄によって、アプリケーションが不正に使用されるというセキュリティ上の問題が発生する可能性が大幅に高まる^[3]。あらゆる可能性を考慮しなければならなくなるため、アプリケーションの動作検証も難しくなる。アプリストアにおけるプライバシーとセキュリティの品質維持の観点から、アプリケーションのパッケージ外部にあるコードを動的に読み込んで実行しないようにポリシーを定めているプラットフォーム^[4]や、ユーザーの同意が得られた場合のみアドオンや拡張機能を取得できるように定めているプラットフォームもある^[5]。

実際に、Adobe Flash Playerのプラグインはセキュリティホールの温床となっており^[6]、iOSプラットフォーム上では最後までサポートされなかった。