hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
Component Object Model
COMを使用して開発されたソフトウェア部品をCOMコンポーネントと呼ぶ。COMコンポーネントの開発は、特定のプログラミング言語に依存せず、C言語やC++、Visual Basic、Smalltalk、Javaなど、様々な言語により開発することができる。COMという用語は、OLE、OLEオートメーション、ActiveX、COM+、DCOMの総称としてよく使われる。COMコンポーネントは、他ソフトウェアと通信するためのインターフェイスを有している。アプリケーションソフトウェア（COMクライアント）は、通信インターフェイスを表現する抽象型として公開されているCOMインターフェイスを介してCOMコンポーネント（COMサーバー）と通信をし、それらを組み合わせることでサービスを提供する。言語によるメモリやその他計算資源の割り付けの違いは、参照カウントを利用してオブジェクトの生成と破棄をそのオブジェクト自身の責任とすることにより解決する。オブジェクトがサポートする、異なるインターフェイス間の型変換は、言語固有のキャスト構文ではなく、言語非依存のQueryInterfaceメソッドで行う。メソッド呼び出しをデリゲート（委譲）する形でサブオブジェクトの集合（アグリゲーションと呼ぶ）を生成する方法がCOM内における最適な継承方法である。
Component Object Model
COMはプロトコルなどの仕様が公開されており、XPCOMのようなクロスプラットフォーム実装も存在するが、COMが主に利用されているのはMicrosoft Windows環境である。MonoにおけるCOM相互運用もMS COMおよびXPCOMを基盤としているが、機能およびサポート環境はまだ限定されている。
COMの前身はOLEである。COMは.NET Frameworkに置き換えられているものも多い。たとえば.NETはDCOMの代替として、Windows Communication Foundation (WCF) を通じてWebサービスをサポートする。WCFがXMLベースのSOAPメッセージを利用するのに対し、ネットワークで接続されたDCOMはバイナリの独自仕様フォーマットを利用する。しかし、Microsoft DirectXなどに代表されるように、ネイティブC++での利用を前提としたパフォーマンス重視のAPIは、依然として.NETではなくCOMが使われる傾向にある。
COMはまたソフトウェアコンポーネントシステムとしてCORBAやJava Beansと競合関係にある。
Component Object Model 技術的詳細
COMコンポーネントにはクラスID (CLSID) が割り当てられ、COMコンポーネント同士はクラスIDによって区別される。CLSIDはGUIDで構成されている。各COMコンポーネントは1つ以上のインターフェイスを公開することで機能を提供している。インターフェイス同士はインターフェイスID (IID) で区別される。IIDもGUIDで構成されている。
COMインターフェイスはプログラミング言語とCOMとを結び付けている。COMコンポーネントへのアクセスは全てインターフェイスを通さなければならない。これによって、プロセスやコンピュータを跨いでCOMコンポーネントにアクセスすることができるようになっている（コンピュータを跨いでのアクセスにはDCOMが必要）。
Component Object Model 技術的詳細
全てのCOMコンポーネントはIUnknownと呼ばれるインターフェイスを継承する必要がある。また、全てのCOMインターフェイスはIUnknownから派生している。IUnknownは、AddRef / Release / QueryInterfaceという3つのメソッドを持っている。AddRefとReleaseはインターフェイスの生存期間を管理するための参照カウントを実装するメソッドである。そしてQueryInterfaceは、IIDを指定してコンポーネントが実装している他のインターフェイスを取得するメソッドである。これはC++のdynamic_castや、JavaおよびC#の型変換演算子に相当する。
Component Object Model 技術的詳細
COMコンポーネントのインターフェイスは、反射性、対称性、推移性を備えている必要がある。反射性とは、あるインターフェイスから、QueryInterfaceをそのインターフェイス自身を表すIIDを与えて呼び出すと、返ってくるインターフェイスは元と同じものでなければならないということである。対称性とは、インターフェイスAからQueryInterfaceでインターフェイスBが取得できる場合、インターフェイスBからインターフェイスAが取得できなければならないということである。推移性とは、対称性と似ているが、インターフェイスBがインターフェイスAから取得でき、インターフェイスCがインターフェイスBから取得できる場合、インターフェイスCはインターフェイスAから取得できなければならないということである。
インターフェイスには、インターフェイスを実装した関数へのポインタをその宣言時の順に並べた仮想関数テーブルへのポインタが含まれている。この関数テーブル構造は、OLE 1.0のときからOLEシステムとの通信に使われていた。
Component Object Model 技術的詳細
COMはコンポーネント間の通信のためにほかにも多くの標準インターフェイスを定めている。たとえばデータストリームを管理するIStreamが挙げられる。これはファイルストリームのコンポーネントがファイルを読み書きする際に使うことが考えられる。IStreamのReadメソッドとWriteメソッドはストリームに対して読み取りと書き込みを行うことが想定される。他の例として、IOleObjectは、あるアプリケーションのデータオブジェクト内に別のアプリケーション向けのデータオブジェクトを埋め込むような複合文書に利用される。IOleObjectインターフェイスは、呼び出した側が呼び出し先コンポーネントとの画面表示上の境界を決められるメソッドや、「開く」あるいは「保存」などのユーザー操作（アクション）に対応する処理を実行することができるメソッドを持っている。
COMではクラスのことをコクラス (coclass) と呼ぶ。コクラスは、COMにおける（オブジェクト指向プログラミングのような）クラスを定義する言語非依存の手段である。
1つのコクラスは、1つ以上のインターフェイスの具体的な実装を提供する。COMに対応しているプログラミング言語であれば、C++、Visual Basicなどどんな言語でも実装を行うことができる。
個々のコクラスは、クラスID (CLSID) やProgIDで識別される。
Component Object Model 技術的詳細
ProgIDによる指定でオブジェクトを作成・取得する際には、ProgIDからクラスIDに変換する必要がある。この変換は一意ではなく、特にバージョン指定のないProgIDでは、インストールされているコンポーネントのバージョン次第で、コンピュータごとに異なるCLSIDとなる可能性がある。
この処理はプログラミング言語やライブラリによって実装される場合もある。VBScriptなど、オブジェクト作成時にProgIDでの指定のみ可能なプログラミング言語もある。
Component Object Model 技術的詳細
COMは、Windows開発の世界に、実装とインターフェイスを切り離すという概念を意識させることをもたらした。この基本的な概念の延長には、オブジェクト指向におけるポリモーフィズム（多態）の実現がある。すなわち、1つのインターフェイスに対して複数の実装（COMサーバー）を用意し、アプリケーション（COMクライアント）側が任意の実装を選び、それを区別なく一様に操作することができるということであり、またCOMコンポーネントが要求するインターフェイスを実装するオブジェクトをアプリケーション側で用意して、COMコンポーネントにインターフェイスを通じて操作させることで、コールバック処理などのカスタマイズを実現することもできるということである。後者はイベントシンク (event sink) として標準化され、プロセス内だけでなくDCOMプロセス間の透過的なコールバック処理をも実現することにつながった。
COMコンポーネントに関する情報の記述手段として、MIDL（マイクロソフトインターフェイス定義言語、IDLも参照）やタイプライブラリがある。MIDLはテキストファイルで主として開発時に用いられる。タイプライブラリは型に関する言語非依存の情報を提供するバイナリファイルであり、開発時だけでなく実行時に参照されることも想定されている。
Component Object Model 技術的詳細
COMコンポーネントの開発では、普通IDLで型を定義することから始める。IDLファイルではオブジェクト指向的なクラスやインターフェイス、構造体、列挙体などのユーザー定義型をプログラミング言語に依存せず記述できる。このIDLではC/C++に似たキーワードと、それに追加してインターフェイスを定義する「interface」、コクラスを定義する「coclass」、それらの集合を現す「library」という2つのキーワードを使用する。また各宣言の前に角括弧[]で括って属性を指定でき、インターフェイスにGUID (IID) を指定したり、配列引数とその長さを示す引数との関係を指示したりできる。
IDLファイルはMIDLコンパイラで様々なプログラミング言語に向けてコンパイルされる。C/C++用にはインターフェイスなどが宣言されたヘッダファイルとGUIDを定義したCのソースファイル、またCOMのメソッド呼び出しをRPC用に変換する「プロキシ」とそれを元に戻す「スタブ」のソースファイルも生成される。
Component Object Model 技術的詳細
MIDLはIDLファイルからタイプライブラリ（.TLBファイル）も作る。タイプライブラリに含まれているバイナリのメタデータはコンパイラや実行環境（Visual BasicやDelphi、.NETのCLRなど）で利用される。その結果タイプライブラリファイルで定義されたコクラスをその言語や環境に持ち込んで使用できるようになる。
COMの基本原則はそれがオブジェクト指向の哲学に基づいているということである。オブジェクト指向開発と実装を実現するためのプラットフォームである。
COMはランタイムフレームワークであるため、型は明示的に識別可能であり実行時に指定可能である必要がある。これを実現するためにGUIDが使われる。それぞれのCOMの型は実行時あるいはコンパイル時に自分の識別用GUIDを指定する。
COMの型についての情報がコンパイル時と実行時の両方でアクセスできるようにする必要性から、COMはタイプライブラリを提供する。COMがオブジェクトの相互作用のための動的なフレームワークとしてその能力を発揮するのはタイプライブラリが効果的に利用されているからである。
以下の例にあるIDLのコクラス定義を考える。
上記のコード断片は、ISomeInterfaceというインターフェイスを実装する、SomeClassという名前のCOMクラスを宣言している。
Component Object Model 技術的詳細
これは概念的には次のようなC++のクラスを定義することに等しい。
ISomeInterfaceはC++の純粋仮想基底クラスに相当するものである。
COMのインターフェイスおよびコクラスを含むIDLファイルはタイプライブラリファイルにコンパイルされる。タイプライブラリはCOMクライアントのコンパイル時あるいは実行時に解釈され、オブジェクトがどのインターフェイスをサポートするかを決定し、オブジェクトのインターフェイスメソッドを呼び出すために利用される。
C++では、Windows API関数のひとつであるCoCreateInstance()を使用してCOMオブジェクトをインスタンス化することができる。引数にはクラスID (CLSID) およびインターフェイスID (IID) を指定する。
この例では、ISomeInterfaceインターフェイスを実装するSomeClassオブジェクトへのポインタを取得するためにCOMサブシステムが使われる。これは概念的に次のようなC++のコードと等しい。
そしてコクラスはCOMの世界ではオブジェクト指向のクラスである。コクラスの主要機能は、(1) バイナリの性質と、(2) 結果的にプログラミング言語に非依存ということである。
Component Object Model 技術的詳細
Windowsの場合、COMのクラス、インターフェイス、タイプライブラリはWindowsレジストリにあるGUIDのリストであり、クラスは"HKEY_CLASSES_ROOT\CLSID"に、インターフェイスは"HKEY_CLASSES_ROOT\interface"にある。COMライブラリは各COMオブジェクトが正しいローカルライブラリを特定するためやリモートサービスのネットワーク上の位置を特定するためにレジストリを使用する。DLLサーバー型のCOMコンポーネントはregsvr32というコマンドラインプログラムを使用してレジストリ登録および登録解除を行なうが、EXEサーバー型のCOMコンポーネントは自身に/RegServerあるいは/UnRegServerスイッチを付けて起動し、レジストリ登録および登録解除を行なう。
Component Object Model 技術的詳細
システムレジストリを使用する性質上、レジストリ登録されたCOMコンポーネントはコンピュータあるいはネットワーク上のすべてのCOMクライアントから共有される。COMコンポーネントをバージョンアップする際にインターフェイスを変更・追加する場合、旧バージョンをレジストリ登録解除したうえで新バージョンをレジストリ登録し直すか、異なる名前およびGUIDを持つインターフェイスを改めて定義した別のコンポーネントをレジストリ登録する必要がある。前者はバージョンアップの際にCOMクライアントの更新は不要だが、破壊的な仕様変更を避けるなど後方互換性に配慮した設計が求められる。後者は新しいバージョンに対応するCOMクライアントを再作成する必要があるが、複数のバージョンを共存させることができ、バージョン間の互換性を考慮する必要はない。たとえばDirect3Dのバージョン7/8/9/10/11/12は、すべて異なるインターフェイスを持つ独立したCOMコンポーネントであり、同一コンピュータ上に共存できる。典型的にいって、COMにおける最良のアプローチは、機能を拡張するためには新しいインターフェイスを定義することである。なおCOMコンポーネントのマイナーバージョンアップの際は、通例既存のインターフェイスを継承して新たなインターフェイスを定義する手法が採られる。たとえばDirect3D 10.1あるいは11.1/11.2/11.3における各インターフェイスは、Direct3D 10.0あるいは11.0のインターフェイスからそれぞれ派生した新しいインターフェイスを定義する方法で機能拡張が行なわれている。
Component Object Model 技術的詳細
Windows XP以降では、「分離アプリケーションとSide-by-Sideアセンブリ」と呼ばれる仕組みを使い、レジストリではなくマニフェストファイルを使用してコンポーネント依存関係を解決することも可能である。この仕組みを用いることで、COMコンポーネントをシステム全体で共有せず、アプリケーションごとにプライベートアセンブリとして配布・運用することも可能となる。
最も基本的なCOMのインタフェースであるIUnknown（全てのCOMインタフェースはここから派生する）は、QueryInterface()による機能の確認と、AddRef()およびRelease()を通じたオブジェクトの寿命の管理という2つの主要な概念をサポートする。参照カウントと機能の確認は（オブジェクトの各インタフェースに対してではなく）オブジェクトに対して適用される。従って注意深く実装する必要がある。
インタフェースへのアクセスを要求したクライアントが存在している限り個々のオブジェクトが生存していることを保障し、逆にオブジェクトを使用していたすべてのコードが終了してそのオブジェクトが不要になった時にオブジェクトを適切に処分するため、インタフェースの参照カウントというテクニックがCOMでは要求される。COMオブジェクトは参照カウントが0に達したときに自分のメモリを自分で解放する責任がある。
Component Object Model 技術的詳細
これを実装するため、COMオブジェクトは一般的に参照カウントのための整数値を持つ。オブジェクトのインタフェースからAddRef()が呼ばれるとこの整数値が加算される。Release()が呼ばれるとこの整数値は減算される。AddRef()とRelease()はCOMオブジェクトのクライアントがそのオブジェクトの寿命に関与できる唯一の手段である。内部の整数値はCOMオブジェクトのプライベートなメンバーであり、直接的にはアクセスできない。
AddRef()の目的は、COMオブジェクトへの新しい参照が生じて、その参照が正当である限り生存し続ける必要があるということを、そのCOMオブジェクトに対して示すことである。Release()の目的は、クライアント（またはクライアントコードの一部）がもうオブジェクトを必要としなくなり、もし参照カウントが0に達した場合にはオブジェクトが自らを破棄するであろうということを示すことである。
Component Object Model 技術的詳細
一部の言語（例えばVisual Basic）では自動参照カウントが提供されるため、COMオブジェクトの開発者はソースコード中で内部参照カウントを明示的に保持する必要がない。C言語でCOMを利用する場合、明示的な参照カウントの操作が必要である。C++では、自分自身でそれを管理することもできるし、参照カウントを全部管理してくれるスマートポインタ（ATL::CComPtrなど）を利用することも選択できる。
下記はCOMオブジェクトで適切な参照カウントの制御を簡単にするためのAddRef()とRelease()を呼び出す際の一般的なガイドラインである。
（戻り値またはoutパラメーターで）インタフェースの参照を返す関数（オブジェクトメソッドとグローバル関数のいずれも）は、それを返却する前に、背後にあるオブジェクトの参照カウントを加算しておくべきである。従って関数やメソッドの内部で、AddRef()が（返却する）インタフェースの参照に対して呼び出される。IUnknownインタフェースのQueryInterface()メソッドはこの実例である。従って、リターンされたインタフェースの参照は既に加算されており、リターンされたインタフェースの参照のAddRefを再度呼びだす必要がないということを開発者は理解していなければならない。
Component Object Model 技術的詳細
COMの開発を容易にして促進するため、マイクロソフトはC++の開発者のためにActive Template Library (ATL) を導入した。ATLは高レベルのCOM開発パラダイムを提供する。ATLはまた、スマートポインタオブジェクトを提供することによってCOMクライアントのアプリケーション開発者が参照カウントを直接管理しなくてもよいようにする。
その他にはMFC、VBScript、Visual Basic、ECMAScript (JavaScript)、Delphiなどのライブラリや言語がCOMに対応している。
COMはクラスファクトリを利用してCOMオブジェクトのインストール（つまり生成）プロセスを標準化する。COMオブジェクトを作成するため、2つの関連した項目が存在していなければならない。
各COMクラスまたはコクラスはユニークなクラスID (GUID) で関連付けられていなければならない。またクラスファクトリとも関連付けられていなければならない（レジストリを利用して行う）。クラスファクトリ自身はCOMオブジェクトである。これはIClassFactoryまたはIClassFactory2インタフェースを持つオブジェクトでなければならない（後者はライセンス管理をサポートしているインタフェースである）。これらのオブジェクトは他のオブジェクトを生成する責任がある。
Component Object Model 技術的詳細
クラスファクトリオブジェクトは一般的にはCOMオブジェクト自身と同じ実行ファイル内（つまりサーバーコード内）に含まれている。ターゲットオブジェクトを作成するようにクラスファクトリを呼び出すとき、このターゲットオブジェクトのクラスIDが提供されていなければならない。このようにしてクラスファクトリはどのクラスのオブジェクトをインスタンス化するのかを把握する。
単一のクラスファクトリオブジェクトは複数のクラスのオブジェクトを生成するかもしれない。すなわち、異なるクラスIDを持つ2つのオブジェクトが同じクラスファクトリオブジェクトによって生成されるかもしれない。しかしながら、これはCOMシステムにとっては曖昧なものではない。
別のオブジェクトにオブジェクト生成の責任を委ねることにより、抽象度が非常に高くなり、開発者に高い柔軟性をもたらす。例えば、シングルトンやその他のオブジェクト生成パターンの実装が容易になる。またファクトリオブジェクトはCOMオブジェクトのメモリ割り当てからアプリケーションの呼び出しを守る。
Component Object Model 技術的詳細
クライアントアプリケーションがクラスファクトリオブジェクトを入手できるようにする必要性から、COMサーバーはそれらを適切に公開しなければならない。クラスファクトリはサーバーコードの特質上、別の方法で公開される。DLL サーバーはDllGetClassObject()というグローバル関数をエクスポートしなければならない。EXEサーバーは実行時にCoRegisterClassObject()というWindows API関数でクラスファクトリを登録しなければならない。
下記はクラスファクトリを利用したオブジェクト生成のシーケンスの一般的な概略である。
Component Object Model 技術的詳細
オブジェクトのクラスファクトリを、Windows API関数CoGetClassObject()で取得する。
CoGetClassObject()を呼び出すためには作成するオブジェクトのクラスIDが提供されていなければならない。C++によるコード例を以下に示す。
IClassFactory* pIClassFactory = NULL;

CoGetClassObject
(
  CLSID_SomeObject,
  CLSCTX_ALL,
  NULL,
  IID_IClassFactory,
  (LPVOID*)&pIClassFactory
);

上記のコードはCLSID_SomeObjectというクラスIDによって識別されたCOMオブジェクトのクラスファクトリが必要であることを示している。このクラスファクトリオブジェクトはIClassFactoryインタフェースで返される。
Component Object Model 技術的詳細
返却されたクラスファクトリオブジェクトを使って元々意図していたCOMオブジェクトのインタフェースを生成するように要求する。C++によるコード例を以下に示す。
ISomeObject* pISomeObject = NULL;

if (pIClassFactory)
{
  pIClassFactory->CreateInstance
  (
    NULL,
    IID_ISomeObject,
    (LPVOID*)&pISomeObject
  ); 

  pIClassFactory->Release();

  pIClassFactory = NULL;
}

上記のコードは、クラスファクトリオブジェクトのCreateInstance()メソッドを使用して、IID_ISomeObjectというGUIDで識別されるインタフェースを公開しているオブジェクトを生成することを示している。このオブジェクトのISomeObjectインタフェースへのポインタが返される。クラスファクトリオブジェクトはそれ自身がCOMオブジェクトであることから、もう必要なければリリースする必要があるということにも注意してほしい（要するにこれのRelease()メソッドを呼び出さなければならない）。
Component Object Model 技術的詳細
上記はオブジェクトをインスタンス化するクラスファクトリの非常に基本的な使用例である。上位レベルのコンストラクタも利用可能であり、その一部はWindows APIを直接利用しないものもある。
例えば、アプリケーションはオブジェクトのクラスファクトリを取得せずにCOMオブジェクトを直接生成するためにCoCreateInstance() APIを利用できる。しかしながら、CoCreateInstance() APIはオブジェクトのクラスファクトリを取得するためにCoGetClassObject() APIを内部で呼び出しており、そしてCOMオブジェクトを生成するためにクラスファクトリのCreateInstance()メソッドを使用している。
CreateObject()というオブジェクトをインスタンス化するためのグローバル関数の他に、C++ではnewを利用できる。C++のコンストラクタはIClassFactory::CreateInstance()メソッドを呼び出して（CoGetClassObject() APIで）目的のオブジェクトのクラスファクトリオブジェクトを取得することを隠蔽する。
PowerBuilderのPowerScriptのように上位レベルのオブジェクトを生成するコンストラクタを提供する言語もある。しかしながらCoGetClassObject()とIClassFactoryインタフェースを使った非常に基本的なオブジェクト生成手法もまだ利用できる。
COMの初期の時代、オブジェクトがどのような機能を提供するのかということをクライアントから確認するためには、インスタンスを実際に生成して（IUnknownインタフェースの）QueryInterfaceメソッドを呼び出してみるしかなかった。
この検証方法は、特定の業務のために適切なコンポーネントを選択したり、オブジェクトが提供するメソッドの使用方法を開発者が理解できるようにしたりといったところで、多くのアプリケーションにとって不便であるということになった。
結果的にコンポーネントを完全に確認できるCOMタイプライブラリが導入された。タイプライブラリは、コンポーネントのCLSID、コンポーネント実装のインタフェースのIID、これらのインタフェースの各メソッドの解説といった情報を含んでいる。タイプライブラリは一般にVisual BasicやVisual StudioのようなRAD環境でクライアントアプリケーションの開発者を支援するために利用されている。
COMは「言語にとらわれない」(language-agnostic) あるいは「言語非依存」(language-independent) のバイナリ標準であり、タイプライブラリすなわちバイナリで定義されたデータ型とインターフェイスを解釈する機能を実装できさえすれば、いかなるプログラミング言語でも開発できる。
ランタイムライブラリ（厳密に言えばプログラマ）は、COMの環境に立ち入って、インスタンス化してCOMオブジェクトの参照をカウントし、バージョン情報からオブジェクトを問い合わせて、新しいバージョンのオブジェクトを利用してコーディングし、新しいバージョンが利用可能でない場合は古いバージョンでも動作するようにフォールトトレラントをコーディングするといった責任がある。
プロセス内から、またはコンピュータ内のプロセスの境界を越えて、あるいはDCOMテクノロジを利用してネットワークを超えて、COMオブジェクトをインスタンス化して参照できる。
プロセスの外やリモートにあるオブジェクトはメソッドコールや戻り値をやりとりするためにマーシャリングを利用できる。
マーシャリングでは、オブジェクトや、オブジェクトを利用しているコードは見えない。
COMでは、アパートメントモデルとして知られているコンセプトによってスレッドの問題を解決している。ここで言うアパートとは、単一のスレッドまたはスレッドのグループの中にある実行コンテキストが1つまたは複数のCOMオブジェクトに関連づけられていることを指している。
アパートメントでは以下のガイドラインが関連するスレッドとオブジェクトのために示される。
COMの世界では、シングルスレッドアパートメント (STA)、マルチスレッドアパートメント (MTA)、中立アパートメント (NA) の3つのアパートメントモデルがある。各アパートメントは、オブジェクトの内部状態が複数のスレッドを超えて同期されるかどうかという1つのメカニズムを表している。
シングルスレッドアパートメントモデルは非常に一般的に利用されているモデルである。ここではCOMオブジェクトはデスクトップアプリケーションのユーザーインタフェースに似た立場にある。STAモデルでは、単一のスレッドがオブジェクトのメソッドを動かすことに専念している。つまり常に単一のスレッドでオブジェクトのメソッドが実行される。このようなアパートメントでは、アパートメントの外にあるスレッドからのメソッドコールはマーシャリングされ、（標準のWindowsのメッセージキューを利用して）システムによって自動的にキューに入れられる。これによりその呼び出しが完了してから各オブジェクトのメソッド呼び出しが実行されるようになり、レースコンディションや同期性の欠如といった心配がない。プロセスの中で最初に作られたSTAは特にメインSTAと呼ばれ、マルチスレッドを全く考慮していないCOMオブジェクトはメインSTAだけで動作させられる。
COMオブジェクトのメソッドの同期を自分で取りたい場合、メソッドを呼び出したスレッドと同一のスレッドでメソッドを処理するようにできる。これをマルチプルスレッドアパートメントと呼ぶ。ただし、STAスレッドからのMTAオブジェクトのメソッド呼び出しはマーシャリングされる。プロセスは複数のCOMオブジェクトで構成でき、その一部をSTAにしてそれ以外はMTAを利用するというようにできる。
COM+で導入されたスレッド中立アパートメントは、オブジェクトのメソッド呼び出しを管理する必要がない場合に用いられる。唯一の条件はオブジェクトの全てのメソッドがリエントラント（再入可能）でなければならないということである。中立アパートメントに属すオブジェクトのメソッドは、STAスレッド・MTAスレッド、どちらからでもマーシャリングなしに直接呼び出せる。
スブタ
スブタ（簀蓋、Blyxa echinosperma）は、トチカガミ科スブタ属の一年草。水田や溝などに群生する沈水性の水草であり、気中葉は作らない。かつては大型のものがナガバスブタ、小型のものがコスブタとされたことがあったが、区別点があいまいで特に分ける意味もないことから現在では呼称はスブタに統一されている。
茎はごく短く、葉は線形で細長く、先はしだいに尖り、茎の基部から根出状に出る。よく育ったものは葉長30cmほどにもなり、水中にくす玉を沈めたような具合になる。葉のサイズは水位によるところが大きい。8 - 10月頃、花茎を水面上に伸ばし、白い花を咲かせる。ただし、花弁が糸状に細く、咲いていてもよく見ないとわからない。1花当たりの花粉数も少なく、ほとんど自家受粉で結実しているものと考えられる。種子は紡錘形で両端に尾状の突起があり、種子の表面には肉眼で確認できるいぼ状の小突起がやや密にある。主な種子散布者として想定されるのは水鳥で、羽に付着したり、泥土ごと足などに付着して運ばれることが考えられる。
国内では本州以南に分布し、国外では東アジア、東南アジアからインドにかけて広く分布している。
スブタ 生育地
水田、休耕田、ため池、流れの緩やかな浅い水路や溝に生育する。かつては普通にみられた水田雑草であったというが、現在ではほとんどみられない稀な水草となっている。減少の要因には、農薬の使用や乾田化や夏季の水落としなど、水田の管理形態の変化による影響が考えられている。湧水を利用した山間部の水田や、農薬をあまり使わない湿田には今でも生育しているところが多い。水田では、稲穂の間に生育している。水田雑草というとイメージは良くないが、スブタは根張りもごく弱く、このように光環境の面からもイネと競合することもないので、イネの収量を落とすようなことはないと思われる。
スブタ 近縁種
日本国内に自生するスブタ以外のスブタ属植物は、マルミスブタ（B. aubertii）、ヤナギスブタ（B. japonica）、セトヤナギスブタ（B. alternifolia）、ミカワスブタ（B. leiosperma）である。このうち、有茎種はヤナギスブタとセトヤナギスブタで、無茎種は上記のスブタ、マルミスブタ、ミカワスブタ（ミカワスブタは有茎の場合もある）である。
有茎種のうちヤナギスブタは茎がよく伸張し、和名どおり柳の茎葉のような姿形になる。日本産スブタ属の中では最も葉幅が狭いこともあり、容易に見分けがつく種である。セトヤナギスブタはヤナギスブタより明らかに葉幅・葉長・花序が大きく、外見上はスブタの茎がやや伸びたような印象である。両種とも茎はしばしば分岐し、また種子にはルーペで確認できるほどの微細な突起が散在するのみで、肉眼ではほとんど平滑である。
無茎種は外見上、葉形・葉の幅・葉長・花序などが互いによく似ており、成熟した種子を観察することで区別される。スブタには種子表面に肉眼でも確認できるいぼ状の突起がやや密にあり、さらに両側に針状の突起がある。マルミスブタはこの両側の突起がない型として別種に扱われている。ミカワスブタの種子表面は前記2種とは異なりほとんど平滑で、ルーペで確認できる程度の突起がまばらにある。
スブタ 近縁種
また、ミカワスブタは残存する標本数も少ないことから、ヤナギスブタと無茎のスブタまたはマルミスブタとの雑種という説や、ヤナギスブタの茎の生長が悪いものとしてヤナギスブタに含める見解がある。しかし生体を観察すれば、葉幅・葉長は明らかにヤナギスブタよりも大きく、種子の形態も異なり、また、ヤナギスブタとミカワスブタが混在する自生地も知られることから、後者の見解は当てはまるとは言いにくい。ミカワスブタは基本的に無茎であるが、生長した株では茎がやや伸長し、しばしば枝分かれするため、有茎型の株の外形はセトヤナギスブタに近い。こうした面も含めて、ミカワスブタについては分類学的な整理が必要である。
スブタ アクアリウムでの利用
アクアリウムにおける水草レイアウトではスブタの仲間はブリクサと呼ばれ人気があるが、よく見かけるブリクサ・ショートリーフはBlyxa novoguiensisであり、スブタとは同属の別種である。時折東南アジア産のスブタ（流通名：ブリクサ・エキノスペルマ Blyxa echinosperma）も水草市場に流通しているが、水槽内での育成は比較的難しい。
森本毅郎
森本 毅郎（もりもと たけろう、1939年〈昭和14年〉9月18日 - ）は、日本のフリーアナウンサー、総合司会者。元NHKアナウンサー、ニュースキャスター。番組制作会社株式会社ラダック（LADAK）の設立者。TBSラジオで30年以上続く長寿番組であり「首都圏で一番聴かれている朝の情報番組」ともなった『森本毅郎・スタンバイ!』のパーソナリティ。また、やはり30年以上の長寿番組となったTBS→BS-TBS『噂の!東京マガジン』の総合司会を務め、テレビドラマや映画などへも出演している。
森本毅郎 来歴
東京府東京市中野区（現在の東京都中野区）で3男4女の7人きょうだいの三男として誕生。兄は評論家の森本哲郎。1944年12月、東京に戦火が落とされるのを恐れ、長野県長野市横沢町へ一家揃って疎開した。
東京都立富士高等学校、慶應義塾大学文学部英文学科を卒業。大学時代は劇研（演劇研究会）に所属し、当時の仲間に石坂浩二がいる。後に石坂が主演した大河ドラマ『草燃える』ではナレーションを担当した。
1963年、NHKにアナウンサーとして入局。入局後は研修を経て、岡山放送局に配属。岡山放送局時代には高校野球の決勝戦中継も経験した。
その後、佐世保放送局（当時、現在は長崎放送局傘下の支局）、神戸放送局を経て東京（本部）へ異動。
1973年から1974年まで『新日本紀行』のナレーターを担当。1974年から1977年まではインタビュー番組『女性手帳』の聞き手役を務める。1977年から1979年までは『教養特集』のキャスターを務め、1980年4月7日からは朝の情報・報道番組『NHKニュースワイド』のメインキャスターを担当した。
1984年2月29日に『NHKニュースワイド』にて「私事で恐縮ですが、今日を持ちまして『ニュースワイド』を卒業します。それと同時にNHKを辞めます」と当時としては異例の「公開フリー宣言」を公表し、2月中に『NHKニュースワイド』を卒業、NHKも退職した。
森本毅郎 来歴
NHKを退局後、TBSと専属契約を交わす。1984年5月7日から冠番組の『森本毅郎さわやかワイド』（ - 同年11月2日）、同年11月5日から『森本ワイドモーニングEye』（後に『モーニングEye』に改題、 - 1987年9月25日）の総合司会を担当。また、個人事務所の「株式会社森本毅郎事務所」を設立し、同社の所属となった。
このTBS専属時代、『ニュース22プライムタイム』のメインキャスター（1987年10月5日 ‐ 1988年9月30日）、『そこが知りたい』の司会（1987年 - 1997年）、『悠々!お昼です』の司会（1990年 - 1991年）、『わいど!ウォッチャー』の司会（1993年 - 1995年）を担当した。なかでも、『噂の!東京マガジン』では1989年10月1日の番組開始より現在まで総合司会を担当している。
1990年からはTBSラジオで冠番組『森本毅郎・スタンバイ!』のパーソナリティを担当する。やがて同番組は「首都圏で一番聴かれている朝の情報番組」の座を確立し、2009年7月に放送5000回、2024年11月に放送9000回を突破した。2025年2月現在も放送回数を増やし続けている。
森本毅郎 来歴
1993年にTBSとの専属契約を解除し、フジテレビやテレビ朝日などにも活動の場を広げる。ただし、日本テレビには出演歴がない。
フリー転身後は、『噂の!東京マガジン』の司会と『森本毅郎・スタンバイ!』のパーソナリティを引き続き担当しながら、フジテレビ・関西テレビ『スーパーナイト』の総合司会（1997年 - 2001年）、TBS『スパスパ人間学!』の司会（1999年 - 2005年）、フジテレビ・関西テレビ『EZ!TV』（後の『情報ライブ EZ!TV』）の総合司会（2001年 - 2005年）、テレビ朝日『グレートマザー物語』のナレーター（2001年4月 - 2007年3月）などを務めた。
2015年11月29日に放送した『噂の!東京マガジン』のエンディングで腰の手術のためしばらく休養することを報告し、2016年1月10日放送分で復帰。2022年4月1日に放送した『森本毅郎・スタンバイ!』のエンディングにて自身5度目となる腰の手術を行うことを公表し、『噂の!東京マガジン』は同年4月いっぱい休演した。
森本毅郎 来歴
2023年6月6日からは発熱のため『森本毅郎・スタンバイ!』を欠席。6月8日までは土井敏之、6月9日放送分は火曜日コメンテーターの酒井綱一郎が代理パーソナリティを務めた。その後、6月12日放送分で一度復帰したが、6月13日には夏風邪の影響による肺炎を患ったとして、体調を考慮し、当面の間は休養することを発表した。それと同時に『噂の!東京マガジン』も休演し、『森本毅郎・スタンバイ!』には6月19日放送分、『噂の!東京マガジン』には6月25日放送分で復帰した。2024年は1月8日放送分から『森本毅郎・スタンバイ!』に出演する予定だったが、当日に発熱があったため出演を見送り、検査入院を経て1月17日放送分から出演した。
2023年に「森本毅郎事務所」を閉鎖・清算し、代わりの個人事務所として「合同会社エン」を設立した。この事務所名には、自らの終活を意識した「もう少しで“エンド”」という意味や、「円」「縁」などの意味が込められているという。
森本毅郎 逸話
職務関連の逸話
2019年11月8日に放送した『森本毅郎・スタンバイ!』において、6時57分頃の「朝刊読み比べ」コーナーが開始する直前、体調不良を訴えて途中退席した。その後、森本は病院で診察を受け、体調を回復した。この日は「スポーツスタンバイ」コーナー担当者で代理パーソナリティ経験者でもある土井敏之が放送終了まで急遽代役を務め、森本は次の放送日である同年11月11日から番組に復帰した。
2021年11月1日に放送した『森本毅郎・スタンバイ!』において、「聞こえねぇんだよ!」と怒声を上げ、アシスタントの遠藤泰子がうろたえたのち、番組がCMに移る場面があった。CM明けは前日（同年10月31日）に行われた第49回衆議院議員総選挙の話題を何事もないように語っていたことから、同番組のリスナーの一部は「森本さんがスタッフに対して怒っていたのではないか?」「ある意味放送事故」とSNSでコメントした。これについて、森本は「ラジオブースの外に副調整室があって、そこから指示を出す人がいるんです。その人の声が小さいうえに、本来ならば『トークバック』という、連絡用の音声系統で話してくれればいいんだけど、それを使わないでブースの外で話しているから『聞こえないんだよ』って」と事実関係を説明している。
パーソナルデータ
森本毅郎 出演
NHK時代
報道番組
報道番組以外（教養・紀行・ドラマなど）
TBS専属時代
報道・情報ワイドショー番組（専属契約解除後も含めて）
バラエティ・特別番組
フリー転身後
TBS
フジテレビ
テレビ朝日
NHK BS
11月25日 (旧暦)
旧暦11月25日は旧暦11月の25日目である。六曜は大安である。
11月26日 (旧暦)
旧暦11月26日は旧暦11月の26日目である。六曜は赤口である。
森美術館
森美術館（もりびじゅつかん）という名称をもつ美術館は、以下の2館がある。
森美術館（もりびじゅつかん）は、東京都港区六本木六丁目の六本木ヒルズ森タワー53階部分に位置する森アーツセンターの核となる美術館施設である。美術館のある地上約230m（53階）は、建物内の展示空間としては日本最高所に位置する。通称は森美術館の英語名称であるMori Art Museumの頭文字を取り、MAM（マム）。
森美術館 概要
森美術館の施設設計は、アメリカ・ニューヨークのホイットニー美術館や、ドイツ・ベルリンのグッゲンハイム美術館等を設計した、リチャード・グラックマン（Richard Gluckman）が担った。
通常のビルでは、賃料を高く設定できる最上部にはオフィスやレストランを誘致するのが定石であるが、六本木ヒルズでは開発を手掛けた森稔（森ビル社長。2012年死去）の六本木を文化都心にしたい。その象徴として、タワー最上部に美術館を据えたいとの理念により、「経済（オフィス）の上に文化（アート）を置く」をコンセプトに開館した。
開館以前、ビルの中に美術館を設ける事例は、国内では出光美術館（東京本館）や百貨店内のミュージアム等に限られていた。そうした中、森美術館の開館は「ビルの中に美術館」を開設する契機になった。
同じ六本木地区にあるサントリー美術館、国立新美術館との3館で「六本木アート・トライアングル」を結成している。
館長は京都造形芸術大学教授で愛知県出身の片岡真実。
森美術館 展示内容
現代美術を中心に絵画や彫刻、建築、ファッション、そしてインスタレーション等で構成された企画展示を行う。欧米からアジアやアフリカに至るまで、世界各地で発信されたあらゆる作品が展示の対象となっている。また、近年に発表された現在進行の表現についても積極的に公開を試みている。開館2年後までは所蔵作品を持たずに企画運営する方針を採っていた。
主な企画展「六本木クロッシング」
森美術館 スタッフ
創立者は森稔（元森ビル株式会社会長＆CEO）、名誉理事長は森佳子（森ビル株式会社取締役）。
嵯峨嵐山駅
嵯峨嵐山駅（さがあらしやまえき）は、京都府京都市右京区嵯峨天龍寺車道町にある、西日本旅客鉄道（JR西日本）山陰本線の駅である。駅番号はJR-E08。「嵯峨野線」の愛称区間に含まれている。
本項では、ほぼ同位置に所在する嵯峨野観光鉄道嵯峨野観光線のトロッコ嵯峨駅（トロッコさがえき）についても述べる。
嵯峨嵐山駅 概要
関西有数の観光名所である嵯峨野・嵐山へのJRにおける玄関口であり、嵯峨野観光鉄道における嵯峨野側の起点駅である。両路線の駅は隣接しており、JRと嵯峨野観光鉄道の駅とを乗り継ぐことができる。
近隣に京福電気鉄道嵐山本線の嵐電嵯峨駅があり（徒歩4分程度）、当駅からの乗換えが可能となっている。なお、渡月橋などの主要な観光地へは、京福電気鉄道の嵐山駅が最寄りである。
嵯峨嵐山駅 歴史
開業時の駅名は嵯峨駅であり、民営化後もこの駅名のままであったが、後に著名観光地である嵐山の名称を加えた嵯峨嵐山駅に改称された。
嵯峨嵐山駅 駅構造
島式ホーム2面4線を持ち、待避設備を備えた地上駅で、橋上駅舎を有する。ホームの有効長は8両編成である。
JR西日本交通サービスに駅業務を委託している亀岡駅管理の業務委託駅。ICOCA利用可能駅（相互利用可能ICカードはICOCAの項を参照）。また、JRの特定都区市内制度における「京都市内」の駅である。
※上表の路線名は旅客案内上の名称（愛称）で表記している。
付記事項
朝夕ラッシュ時に快速と普通の緩急接続が行われる。奇数番線（1番のりば・3番のりば）が主本線、偶数番線（2番のりば・4番のりば）が待避線である。また、京都方に片渡り線があるため、3・4番のりばから京都方面へ発車することもできる。2017年3月4日改正で設定された当駅始発の京都行き列車は4番のりばから発車する。複線化工事完成以前は単式・島式の複合型2面3線で、2番のりばを上下共用の待避線とした構成であった。
その他
嵯峨嵐山駅 駅構造
2007年3月17日までは、1897年に京都鉄道の駅として開業した当時の駅舎（使用終了時点でJR西日本では最古の現役駅舎）を改装して使用していた。1994年までは貴賓室も備えていたほか、レトロかつモダンな駅舎が周囲の風景に溶け込んでいたが、京都 - 園部間完全複線化に向けた橋上駅舎への改築のために2007年3月18日からは仮駅舎が使用され、旧駅舎は仮駅舎の陰に隠れた。その後、2007年6月に旧駅舎の解体作業が始まり、歴史ある駅舎は姿を消した。2008年6月14日から現在の橋上駅舎の使用開始に伴い、旧駅舎側が南口となったほか、新たに北口と南北自由通路が設置された。また、北口には新駅舎完成時からエスカレーターが、南口側はエレベーターが改築当初からそれぞれ設置されていたが、エスカレーターは仮駅舎を撤去した跡に設置されたため、橋上駅舎の開業から少し遅れて同年11月21日に使用開始となった。駅舎は和風の内外装を持ち、付近の景観に溶け込むように配慮されている。さらに、南口側の駅前広場（2500m2）が2009年2月28日から、北口側の取り付け道路と駅前広場は2009年3月14日からそれぞれ使用開始となった。
嵯峨嵐山駅 駅構造
単式ホーム1面1線の地上駅。駅舎は開業6周年を記念して総工費3億円で建設され、外壁がレンガ風の鉄骨造2階建て。旧駅舎の4倍の面積となり、直径3mのシャンデリアが設置されている。
JR西日本の嵯峨嵐山駅とは独立した駅舎を持っており、乗り換えの際も一旦改札から出る必要があるが、当駅からトロッコ嵐山駅までの間は山陰本線と線路を共用しているため運転取り扱い上では嵯峨嵐山駅と同一駅扱いとなっており、同駅の「5番線」として扱われている。
駅舎と並んで、19世紀の科学技術や芸術を展示している「19世紀ホール」があり、C58形などの蒸気機関車などが展示されている。駅舎内と「19世紀ホール」はつながっており、嵯峨野観光線の営業時に無料で自由に内部が見学できる。このほか、駅構内には嵯峨野観光鉄道の本社が置かれている。
嵯峨嵐山駅 利用状況
2023年度の1日当たりの利用者数は17,080人。1日の平均乗車人員は以下の通りである。
各年度の1日平均乗車人員は下表の通り。
嵯峨嵐山駅 駅周辺
駅の西側や北側が、一般には嵯峨野と言われている地域であり、南西方向が嵐山である。主な観光地はいずれも駅からやや離れているが、今や嵐山・嵯峨野地区を代表する観光スポットのひとつである嵯峨野観光線が乗り入れているため、同路線へ乗り継ぐ利用者が多く見られる。他社の嵐山駅と比較すると、京都駅から乗り換えなしで到達できることが当駅の利点となっている。
嵐電嵯峨駅（京福電気鉄道嵐山本線）は南へ徒歩約4分、阪急嵐山駅は渡月橋を渡って南東方向へ徒歩約20分。
駅前から京都府道135号嵯峨嵐山停車場線が発し、天龍寺方面へ通じる。
嵯峨嵐山駅 バス路線
2009年3月28日の市バスダイヤ改正により、「嵯峨嵐山駅前」のバス停が新設された。
角倉町（駅南側）
京都市バス（東行のみ）
11号系統：四条河原町・三条京阪
京都バス
62系統：四条河原町・三条京阪 / 清滝
63系統：四条河原町・三条京阪 / 苔寺すず虫寺
66系統：四条河原町・三条京阪 / 阪急嵐山駅前
67系統：四条河原町・三条京阪
72系統：京都駅前 / 清滝
快速72系統・快速76系統・81系統：京都駅前
73系統：京都駅前 / 苔寺・すず虫寺
76系統：京都駅前 / 阪急嵐山駅前
83系統：苔寺・すず虫寺
嵯峨嵐山駅 隣の駅
西日本旅客鉄道（JR西日本）
嵯峨野線（山陰本線）
■快速
円町駅 (JR-E05) - 嵯峨嵐山駅 (JR-E08) - 亀岡駅 (JR-E11)
■普通
太秦駅 (JR-E07) - 嵯峨嵐山駅 (JR-E08) - 保津峡駅 (JR-E09)
嵯峨野観光鉄道
■嵯峨野観光線
トロッコ嵯峨駅 - トロッコ嵐山駅
フランスパン (同人サークル)
フランスパン（Soft Circle French-Bread）は、同人ゲームサークル。
フランスパン (同人サークル) 概要
『魔物ハンター舞』・『えあふり』・『THE QUEEN OF HEART』・『PARTY'S BREAKER』・『MELTY BLOOD』など数多くのゲームを発表してきた渡辺製作所のメンバーによって2003年に設立された。2012年9月20日に初の商業オリジナル作品『UNDER NIGHT IN-BIRTH』（アンダーナイト インヴァース）をリリース。
サークル名の由来は、代表のなりたのぶやが渡辺製作所の設立以前に所属していた同人サークルの名前をそのまま再利用したことによるもの。従って、フランスパンという同人サークルには新旧2種類のものが存在することになるが、ここでは新しい方についてのみ記載する。
フランスパン (同人サークル) 商業作品
UNDER NIGHT IN-BIRTH
2012年9月20日稼動のアーケード用対戦格闘ゲーム。『MELTY BLOOD Act Cadenza』と同じくエコールソフトウェアが販売。ALL.Net P-ras MULTI対応第1弾ソフト。
電撃文庫 FIGHTING CLIMAX
2014年3月18日稼動のアーケード用対戦格闘ゲーム。SEGA発売によるALL.Net P-ras MULTI対応ソフト。
MELTY BLOOD: TYPE LUMINA
2021年発売の家庭用ゲーム機など(Nintendo Switch、PlayStation 4、Xbox One、Steam)用対戦格闘ゲーム。原作ゲーム『月姫』のリメイク版である『月姫 -A piece of blue glass moon-』に準拠した世界観に改められ、ゲームシステムも一新されている。発売はディライトワークス。
フランスパン (同人サークル) 同人作品
Rosa Chinensis Four hand -紅薔薇連弾-
2003年5月頒布の旗揚げ作品。人気小説『マリア様がみてる』を題材に取った縦スクロールタイプのシューティングゲーム。発行部数が極めて少ない上重版もされず、幻のデビュー作となった。
バイクバンディッツ
2003年8月17日頒布。メンバーの来兎がかつて制作に関わった横スクロールタイプシューティングゲーム『ウィザーズスター』（1997年発表、NEXT）のリメイク。渡辺製作所時代を含め、初のオリジナル作品である。
主題歌「flyHigh」は片霧烈火が歌い、サウンドトラック盤「サントラバンディッツ」にはのちに来兎とともに音楽ユニット「風葉」を組むこととなるりお☆るか（現:綾菓）も参加した。
どりるみるきーぱんち
2003年11月日頒布。近年では珍しいクォータービュー（斜め見下ろし）タイプのアクションゲーム。『マブラヴ』などアージュ製ゲームのキャラクターが、全方位から来る敵を攻撃する。
MELTY BLOOD Re・ACT
2004年5月30日頒布。『MELTY BLOOD』のアップグレードディスク。
RAGNAROK BATTLE OFFLINE（日本語版） / RAGNAROK BATTLE（日本国外版）
フランスパン (同人サークル) 同人作品
2004年12月30日頒布。MMORPG『ラグナロクオンライン』の世界観をベースにした横スクロールアクション。オリジナルはイラストレーター・南向春風が2002年に発表したフラッシュムービー『RAGNAROK BATTLE ONLINE』で、これを見た『ラグナロクオンライン』の開発元・韓国グラヴィティが渡辺製作所にゲーム化を要請したと言う経緯を持つ（グラヴィティは南向が渡辺製作所のメンバーであり、渡辺製作所は商業メーカーであると誤解していた節があったようだ）。後に技術的な問題からネットワークプレイを断念せざるを得なくなり、タイトルが「ONLINE」から「OFFLINE」に修正された。日本では当初の予定通りフランスパンの同人ソフトとして公開。2006年には主題歌「砂塵の彼方へ」がリリースされた。
フランスパン (同人サークル) 同人作品
韓国では『RAGNAROK BATTLE』の名前で、USBパッドと『ラグナロク…』のゲーム内アイテムを付属したPC版がグラヴィティより発売中、PSP版が発売予定となっている。
4Gamer、Gparaなど、企業が運営するゲームニュースサイトのライターに販売方式を間違えられたことがある。
イニシャルでG社とは日本で『ラグナロクオンライン』を運営するガンホーではなくGravityのことで、ガンホーは本作には全く関わっていない。
ゲーム中には日本の『ラグナロクオンライン』でよく見かける光景（（罠）BOTの逆毛剣士、溜め込み、トレイン、横殴り、通報しますた、等）や一部キャラクターの名前（バーチャルネットアコライトさやさや16歳、チェき14歳、歌唄いメセナ、Soul ～、GM001.Sei（ガンホー技術担当取締役：堀誠一）、GM012等）、ガンホー蔑称ネタなどブラックジョークが溢れている。これらの点についてフランスパンのなりたは「悪意があってやっているわけではないからグラヴィティとガンホーに文句を言わないでほしい」とコメントしている。
開発の際、「FLASHの再現を望む『同志』として、海を越え、国を越えた熱い絆で結ばれた関係なのであります」とコメントした。
韓国のPSP版リリース予定については「『断る理由がないので善処する』と日本人的に答えておきました」とコメントした。