マイクロソフト(株) : 磯貝 直之氏

Windows 2000チーム徹底インタビュー (その4)　Office 2000は、企業アプリケーションのプラットフォームである～Office 2000 Developer～

[編集部] Officeアプリケーションを「マクロ中心」に使っているユーザー、つまり、Officeアプリケーションを「プラットフォーム」として使っているユーザーにとっては、たとえばExcelのマクロを書いて、それを実行しようとした場合、どうしてもExcelでないと実行できないことになる。しかも、マクロの埋め込まれたExcelのファイルを見つけ出してきて、そのファイルを開かなければならない。つまり、Excelをプラットフォームとした瞬間に、そのプラットフォームがExcelだけに限定されてしまうことになるわけです。私は、通常のOffice 2000で可能なのは、あくまでもマクロまでであって、アプリケーションの中に閉じこもった形で限定されてしまっているのではないかと考えているのですが。

[磯貝] 「Office 2000 Developer」の大きな特徴の1つに、「COMアドイン」の開発機能が挙げられます。ご指摘のとおり、マクロの場合は、実際に埋め込まれた各アプリケーションのドキュメントをオープンしなければならない。また、複数のユーザーがソリューションを共有したい場合には、ドキュメントファイルの区別や、ファイルそのものを探し出すのに混乱するケースが多かったのは事実です。

　「COMアドイン」は、完全にアプリケーションの側に組み込まれるため、同一のOffice環境であれば、どのアプリケーションからも同じ「COMアドイン」を利用できます。逆に「COMアドイン」はDLLとして実装されるために、DLLの配置は任意ですが、Officeアプリケーションからでないと利用できません。これらをまとめて言えば、「VBAを搭載しているすべてのOffice 2000アプリケーションから、統一的に呼び出すことの可能なアドインプログラムがCOMアドインである」と表現できます。つまり、いままでExcelをプラットフォームとしてVBAで実現していたソリューションを、「COMアドイン」として作成することによって、Excelだけではなく、WordやAccessなどを含めたほかのアプリケーションからも呼び出すことが可能となるわけです。今まで1つのアプリケーションでしかプラットフォームにできなかったものが、すべてのOfficeアプリケーションという、より広いプラットフォームをターゲットとした開発が可能となるわけです。

[編集部] まず、「COMアドイン」といった名称からして難しそうです。VBAをある程度使い慣れているユーザーにとっても、その名前からして難しいと受け止められてしまうのではないでしょうか。

　また、開発ツールは、どのようなものが用意されているのでしょうか。

[磯貝] 開発ツールからご説明しますと、「Office 2000 Developer」には、COMアドインの開発を容易にするための「COMアドインデザイナ」が付属しています。この「COMアドインデザイナ」を使うと、いままでマクロを書いていたのとあまり変わらない感覚で「COMアドイン」を作成することができます。

　また、名称に「COM」と付いていると、難しそうに感じますが、実際に「COMアドイン」を作成する方法は、マクロを書く方法と変わりません。「Office 2000 Developer」と言っても、環境はVBAが基本となるわけですから。

　開発環境は、通常のVBエディタとほとんど変わりません。実は、「Office 2000 Developer」をインストールすると、［ファイル］メニューに［プロジェクトの追加］［プロジェクトの作成］などといったコマンドが追加されるのです。ここで［プロジェクトの作成］から［アドインプロジェクト］を選択すると、「アドイン・デザイナ」を起動することができるというわけです。

「アドイン・デザイナ」では、「アドインの表示名」や、実際にアドインをどのアプリケーションで利用するか、アプリケーションのバージョンや、アプリケーションの中で起動するタイミングを選択できます。また、Excelが起動した瞬間に、そのCOMアドインも起動したい場合は「スタートアップ」に指定する方法や、メニューの中などに追加して、必要な時だけ使用したい場合は「ロードオンデマンド」を指定する方法も選択可能です。デザイナ上での作業はもちろん、フォームの挿入や標準モジュールの挿入といった作業は、ほとんどマクロを書くのと同様の操作で可能です。ですから、VBエディタの中でプログラミングができれば、特に障壁はありません。

　プログラミングされコンパイルされた「COMアドイン」は、DLLにまとめられます、使用する場合は、特定のアプリケーションの［メニューのカスタマイズ］から［COMアドインメニューの追加］で指定します。そこで、DLLを指定すると、その瞬間にレジストリへの登録が行なわれ、アプリケーションからCOMアドインを呼び出すことができるようになります。つまり［ツール］メニューに追加されるわけです。

　たとえば、Word用にマクロを書いた場合、これまでは同じマクロを別のアプリケーション用に別途書かなければならなかった。「COMアドイン」には、Word以外のほかのアプリケーションで使用するためのコードも記述することができるため、ほかのアプリケーションから同じ操作を行なうことによって、まったく同じ機能を呼び出すことができるわけです。何かVBAを使ってソリューションを作った場合、1つのアプリケーションの中だけに留めておくのは非常にもったいない。特に汎用性の高いソリューションであれば、なおのことです。こういった場合にはCOMアドイン化して、Officeをターゲットとしたアプリケーション、つまりより汎用性の高いアプリケーションを作成していただきたいのです。

[編集部] 今のお話をまとめますと、Officeアプリケーションをプラットフォームとして、その環境をメインに作業をしているユーザーにとっては、VBAに対して汎用性を持たせ「COMアドイン」としてまとめることによって、各アプリケーション間で、共通に利用可能なモジュールを作成することができるというわけですね。内部的なお話をしていただけますか。

[磯貝] 内部的には、コンパイルしたDLLにインターフェイスを持たせておき、そのインターフェイスを通じて各アプリケーションとの連携を行なうという処理が行なわれます。具体的には、「COMアドイン」専用の「IDTExtensibility2」というインターフェイスがあります。これを実装してるDLLは、Officeアプリケーションから呼び出し可能となるわけです。「COMアドイン」の実体はDLLが1つだけで、たとえばほかのリソースファイルなどは必要ありません。Office自体がリソースファイルであり、ランタイムの役割を果たすわけですから、Officeがインストールされている環境では、DLLのやり取りだけで実行可能となるわけです。

　また、企業内でのマクロを配布して利用する場合、ユーザーが勝手にコードを書き換えてしまうといったセキュリティ上の問題も発生する可能性があります。こういった問題に対処するには、COMアドイン化してしまえば、完全にDLL化されるためコードのセキュリティは保てるわけです。特に企業内における各部門での管理といった面も考え合わせると、COMアドインでの配布は有効な手段であると思います。社内ネットワークでの配布に際しても、トラフィックの面から考えて、マクロをOfficeドキュメント本体とともに配布するよりも、サイズの小さなCOMアドインでの配布は有効な手段となるでしょう。作るほうも使うほうも、管理しやすく使いやすいというわけです。