Office のサーバーサイド オートメーションについて

適用対象: Office ProductsAccess 2010Excel 2010

概要


開発者は Microsoft Office のオートメーションを使用して、Office 製品に組み込まれている能力や機能を使用するカスタムソリューションを構築できます。 このようなプログラムの開発は、クライアント システムでは比較的簡単に実装できますが、Microsoft Active Server Pages (ASP)、ASP.NET、DCOM、Windows NT サービスなど、サーバーサイド コードからオートメーションを実行する場合は複雑な問題が多数発生する可能性があります。

この資料は、開発時に直面する可能性がある複雑な問題について説明します。 また、パフォーマンスを向上できるオートメーションの代替機能についても説明します。 ただし、この資料が情報提供のみを目的とした提案である点に留意してください。 マイクロソフトは、Office のサーバーサイド オートメーションを推奨またはサポートしていません。

注: この資料内では、Microsoft 2007 Office System Driver と 2010 Access Database Engine を Microsoft Office コンポーネントとして扱います。 "サーバーサイド" という用語は、ログインしているユーザーの対話型ステーションではなく、Windows ワークステーションからコードが実行される場合、Windows ワークステーション上で実行されるコードにも適用されます。 たとえば、SYSTEM アカウントでタスク スケジューラによって開始されたコードは、"サーバーサイド" の ASP コードまたは DCOM コードと同じ環境で実行されます。 そのため、この資料で説明する多くの問題が発生する可能性があります。 Windows ワークステーションと COM の詳細については、「関連情報」セクションの「詳細情報」を参照してください。

詳細情報


Microsoft Office のすべての現行バージョンは、クライアント ワークステーション上のエンドユーザー製品として実行されるように設計、テスト、および構成されました。 また、対話型デスクトップとユーザー プロファイルが想定されています。 無人で実行されるように設計されたサーバーサイド コンポーネントのニーズを満たす必要があるレベルの再入機能またはセキュリティは提供していません。

マイクロソフトは、現在のところ、無人の非対話型クライアント アプリケーションまたはコンポーネント (ASP、ASP.NET、DCOM、および NT サービスを含む) からの Microsoft Office アプリケーションのオートメーションに関して、推奨もサポートも行っていません。それは、このような環境で Office を実行した場合、Office で不安定な動作やデッドロックが発生する可能性があるためです。

サーバーサイドのコンテキストで実行されるソリューションを構築する場合は、無人で実行しても安全な設計のコンポーネントを使用してみることをお勧めします。 または、少なくともコードの一部がクライアント側で実行される代替コンポーネントを探すことをお勧めします。 サーバーサイド ソリューションから Office アプリケーションを使用する場合、アプリケーションが正常に実行されるために必要な多くの機能がありません。 さらに、ソリューション全体の安定性についてリスクを見込むことになります。

Office のオートメーションをサーバーサイドで使用する際の問題

サーバーサイド ソリューションで Office を使用する開発者は、環境が原因で Office が期待とは異なる動作になる主な領域 5 つについて気を付ける必要があります。 コードが正常に実行される場合、これらの問題に対処し、可能な限り多くの影響を最小限に抑える必要があります。 アプリケーションを構築するときは、これらの問題について慎重に検討します。 1 つの解決策では、すべての問題に対処できません。 設計によって、優先する要素は異なります。

  • ユーザー ID: オートメーションによって Office アプリケーションが起動する場合でも、アプリケーション実行時にユーザー ID が想定されています。 アプリケーションを起動したユーザーのユーザー レジストリ ハイブの設定に基づいて、ツールバー、メニュー、オプション、プリンター、一部のアドインの初期化が試行されます。 多くのサービスは、ユーザー プロファイルがないアカウント (SYSTEM アカウント、IWAM_[サービス名] アカウントなど) で実行されています。 そのため、Office が起動時に正しく初期化されないことがあります。 この場合、CreateObject 関数または CoCreateInstance 関数のエラーが Office から返されます。 Office アプリケーションを起動できても、ユーザー プロファイルが存在しない場合、他の関数が正常に動作しない可能性があります。
  • デスクトップとの対話機能: Office アプリケーションは、対話型デスクトップで実行されることを想定しています。 状況によっては、特定のオートメーション機能が正常に動作するために、アプリケーションを可視化する必要があります。 予期しないエラーが発生した場合、または関数を完了するために不明なパラメーターが必要な場合、Office はモーダル ダイアログ ボックスを表示し、実行する動作をユーザーに確認するように設計されています。対話型ではないデスクトップのモーダル ダイアログ ボックスを閉じることはできません。 そのため、そのスレッドは永久に応答しなくなります (ハングします)。 コーディング方法によってこの問題が発生する可能性を軽減できる場合もありますが、このような方法で問題全体を回避することはできません。 そのため、サーバーサイド環境から Office アプリケーションを実行することは危険であり、サポートされません。
  • 再入機能とスケーラビリティ: サーバーサイド コンポーネントは、複数のクライアントに対応するために最小限のオーバーヘッドで高いスループットを持つ、再入性が高いマルチスレッドの COM コンポーネントである必要があります。 Office アプリケーションは、ほぼすべての点でその反対のアプリケーションです。 Office アプリケーションは、再入機能がない STA ベースのオートメーション サーバーであり、1 つのクライアントに対して多様でリソースを大量に消費する機能を提供するように設計されています。 また、サーバーサイド ソリューションとしてのスケーラビリティをほとんど提供していません。 さらに、メモリなどの重要な要素に対して固定の制限があります。 これらの制限は構成で変更できません。 さらに重要な点は、Office アプリケーションが、メモリ マップ ファイル、グローバル アドインまたはテンプレート、共有オートメーション サーバーなどのグローバル リソースを使用していることです。 そのため、複数クライアント環境で Office アプリケーションが構成されると、同時に実行できるインスタンス数が制限され、競合条件が発生する可能性があります。 同時に複数インスタンスの Office アプリケーションを実行する予定の場合、開発者は、"プーリング" または Office アプリケーションへのアクセスをシリアル化して、デッドロックやデータ破損の可能性を回避することを検討する必要があります。
  • 回復性と安定性: Office 2000、Office XP、Office 2003、および Office 2007 は、Microsoft Windows インストーラー (MSI) テクノロジを使用して、エンド ユーザーがインストールと自動修復を簡単に実行できるようにしています。 MSI は、"初回使用時のインストール" という概念を導入しました。 この概念によって、システムまたは 1 人のユーザー (多くの場合はこちら) の実行時に機能を動的にインストールまたは構成できます。 サーバーサイド環境では、この概念によってパフォーマンスが低下し、インストールの承認またはインストール ディスクの挿入をユーザーに求めるダイアログ ボックスが表示される可能性が高くなります。 この機能はエンドユーザー製品として Office の回復性を高めるために設計されましたが、Office の MSI 機能の実装はサーバーサイド環境では逆効果です。 さらに、一般的には、Office をサーバーサイドで実行する場合、Office の安定性を確保できません。これは、サーバーサイドで実行する目的で設計やテストが行われていないためです。 ネットワーク サーバー上のサーバー コンポーネントとして Office を使用すると、コンピューターの安定性が低下し、結果としてネットワーク全体の安定性が低下する可能性があります。
  • サーバーサイドのセキュリティ: Office アプリケーションは、サーバーサイドで使用するように設計されていません。 そのため、Office アプリケーションは、配布されたコンポーネントで発生するセキュリティの問題を考慮していません。 Office は受信要求を認証しません。 また、サーバーサイド コードから、予期しないマクロの実行や、マクロを実行する可能性がある他のサーバーの起動を阻止する機能もありません。 匿名の Web サイトからサーバーにアップロードされたファイルは開かないでください。 サーバーでは、最後に設定されたセキュリティ設定に基づいて、すべての特権を持つ Administrator または System のコンテキストでマクロが実行され、結果としてネットワークが悪用される可能性があります。 また、Office は処理を高速にするために、クライアントの認証情報をキャッシュできる多くのクライアント側コンポーネント (Simple MAPI、WinInet、MSDAIPP など) を使用しています。 Office がサーバーサイドで自動化されている場合、1 つのインスタンスで複数のクライアントにサービスを提供する可能性があります。 そのセッションで認証情報がキャッシュされると、あるクライアントが別のクライアントのキャッシュ済み資格情報を使用する可能性があります。 結果として、そのクライアントは他のユーザーになりすまして許可されていないアクセス許可を得る可能性があります。

技術的な問題とは別に、ライセンスの問題も考慮する必要があります。 現在のライセンス ガイドラインでは、クライアントにライセンス認証済みの Office がインストールされている場合を除き、クライアント要求を処理するサーバー上で Office アプリケーションを使用することは禁じられています。 サーバーサイド オートメーションを使用して、ライセンス認証されていないワークステーションに Office 機能を提供することは、ソフトウェア ライセンス条項 (EULA) では認められていません。

このような問題以外にも、オートメーションによってサーバーサイドで Office を呼び出したときに、次のいずれかのエラーが共通して発生することがあります。

  • CreateObject 関数および CoCreateInstance 関数が次のいずれかの実行時エラー メッセージを返し、オートメーションに対して起動できません。
     
    メッセージ 1
    実行時エラー '429': ActiveX コンポーネントはオブジェクトを作成できません
    メッセージ 2
    実行時エラー '70': アクセス許可が拒否されました
    メッセージ 3
    CO_E_SERVER_EXEC_FAILURE (0x80080005): サーバーの実行に失敗しました
    メッセージ 4
    E_ACCESSDENIED (0x80070005): アクセスが拒否されました
  • Office ドキュメントを開くときに、以下のいずれかのエラー メッセージが表示されます。
     
    メッセージ 1
    実行時エラー '5981' (0x800A175D): マクロの記憶領域を開くことができません
    メッセージ 2
    実行時エラー '1004': オブジェクト '~' のメソッド '~' が失敗しました
  • CreateObject 関数と CoCreateInstance 関数は応答せず、完了しなくなるか、復帰に時間がかかるようになります。 サーバーによっては、作成は高速に完了しますが、アプリケーションが停止したことを示す 1004 が Windows イベント ログに記録されることがあります。
  • ある種の関数は、ユーザー警告、またはユーザーの注意を必要とするその他のダイアログ ボックスにより、突然失敗したり、無限に応答を停止したりします。
  • 複数の要求またはストレス テストを実行すると、コードが失敗する、応答しなくなる、Office アプリケーションの作成または停止時にクラッシュする問題が発生します。 この問題が発生すると、プロセスが実行中のままメモリに残り、停止できなくなるか、自動化されているアプリケーションのすべてのインスタンスがその時点から失敗します。

ここに示す以外にも、その他の問題が発生したりメッセージが表示されたりすることもありますが、これらの問題は通常、この資料で前に示した 5 つの主要な問題の結果として生じるものです。 

サーバーサイド オートメーションの代替方法

サーバーサイド ソリューションを開発する必要がある場合は、Office のオートメーションの代替方法を探すことをお勧めします。 Office の設計には制約があるため、Office の設定に変更を加えてもすべての問題を解決するには不十分です。 マイクロソフトは、サーバーサイドに Office をインストールする必要がなく、オートメーションより効率よく迅速に共通のほとんどのタスクを実行できるいくつかの代替策を強くお勧めします。 Office をサーバーサイド コンポーネントとしてプロジェクトに含める前に、代替策について検討してください。

ほとんどのサーバーサイド オートメーション タスクは、ドキュメントの作成または編集を伴います。 Office 2007 は、新しい Open XML ファイル形式をサポートしています。開発者はこの形式を使用して、サーバーサイドでファイル コンテンツの作成、編集、読み取り、変換を行うことができます。 これらのファイル形式では、Office クライアント アプリケーション自体を使用せずに、Microsoft .NET 3.x Framework の System.IO.Package.IO 名前空間を使用して Office ファイルを編集しています。 これは、サービスから Office ファイルの変更を処理する場合に推奨され、サポートされている方法です。

Open XML ファイル形式はパブリック スタンダードです。 


マイクロソフトでは、.NET 3.x Framework から Open XML ファイル形式を操作するための SDK を提供しています。 SDK の詳細と、SDK を使用して Open XML ファイルを作成または編集する方法については、次の Microsoft Developer Network (MSDN) Web サイトにアクセスしてください。

ASP または ASP.NET から Open XML ファイルをストリーム出力する場合は、ストリーム出力するコンテンツ用の適切な MIME (Multipurpose Internet Mail Extension) の種類を用意する必要があります。 Office 2007 ファイル用の MIME の種類の一覧については、次の Web サイトを参照してください。

Office 2007 よりも前のクライアントのみを対象としていて、ソリューションで Open XML を使用する必要がない場合、HTML、XML、RTF など、その他の非バイナリ Office ファイル形式を使用することができます。 続いて、結果のテキストが Office で表示されるように、MIME の種類を使用することでこれらのファイルをクライアントにストリーム出力することができます。 サーバー上で ASP を使用することにより、ドキュメントを編集したり保存したりするだけでなく、サーバーに返すこともできます。

これらのトピック、および実装方法の例の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。

198703 クライアント側 VBScript から Excel を自動化する方法
278973 ADO を使用して Excel ブックのデータの読み取りおよび書き込みを行う方法 (ExcelADO)
286023 VB ActiveX コンポーネントを使用して Internet Explorer から Word オートメーションを使用する方法
 

業務上、サーバーサイドで Office 97、Office 2000、Office XP、および Office 2003 のバイナリ ファイル形式を作成する必要がある場合は、サードパーティ ベンダーが提供する役立つコンポーネントがあります。 マイクロソフトはこのようなコンポーネントを提供しないため、自分でソリューションを構築するか、サードパーティ ベンダーからソリューションを購入する必要があります。 数多くのさまざまなサードパーティ製品が利用できます。 各ソリューションを調べて、業務に最適なベンダーを探すことをお勧めします。

Office 97、Office 2000、Office XP、および Office 2003 のバイナリ ファイル形式を直接編集する独自のソリューションを構築する必要がある場合は、Microsoft Open Specification Promise (OSP) の条項の下で無料であるファイル形式の仕様を入手できます。 ユーザーが作成するドキュメントまたは製品に対するテクニカル サポートは提供されませんが、ドキュメントの利用は可能です。 


サーバーサイド ソリューションでは、ファイルをアップロードすることをユーザーに許可し、Web などのメディアで表示するためにサーバーでファイルを作成することが必要な場合があります。 現時点でマイクロソフトはこのような機能を提供するための作業を行っています。また Microsoft Excel Services でこの機能の初期バージョンを提供しています。

Excel Services は、Microsoft Office SharePoint Server 2007 に搭載されている新しいサーバー テクノロジです。このサービスを使用すると、Office SharePoint Server 2007 での Excel ブックの読み込み、計算、および表示が可能になります。 Excel Services の詳細については、以下の MSDN (Microsoft Developer Network) Web サイトを参照してください。

Word Automation Services は、SharePoint Server 2010 の新しいサービス アプリケーションです。 Word Automation Services は、文書を Microsoft Word クライアントでサポートされている形式に自動的にサーバーサイドで変換します。この資料に記載されているどの方法がニーズを満たし、ソリューション展開に最適化かを評価する必要があります。 この資料で説明した内容によって、すべてのクライアントのあらゆる問題が解決されるかどうかは保証されません。 ソリューションを十分にテストしてから展開してください。