メイン コンテンツへスキップ
サポート
Microsoft アカウントでサインイン
サインインまたはアカウントを作成してください。
こんにちは、
別のアカウントを選択してください。
複数のアカウントがあります
サインインに使用するアカウントを選択してください。

概要

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

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

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

詳細情報

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

Microsoft では、無人の非対話型クライアント アプリケーションまたはコンポーネント (ASP、ASP.NET、DCOM、NT Services を含む) からの 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 では、"初回使用時にインストールする" という概念が導入されています。 これにより、システムの実行時に機能を動的にインストールまたは構成したり、特定のユーザーに対してより頻繁に機能をインストールしたり構成したりできます。 サーバー側環境では、パフォーマンスが低下し、ユーザーにインストールの承認またはインストール ディスクの提供を求めるダイアログ ボックスが表示される可能性が高くなります。 これは、エンド ユーザー製品としての Office の回復性を高めるために設計されていますが、Office の MSI 機能の実装は、サーバー側環境では逆効果です。 さらに、この種類の使用のために設計またはテストされていないため、Office がサーバー側で実行されている場合、一般的な Office の安定性は保証されません。 ネットワーク サーバーで Office をサービス コンポーネントとして使用すると、そのコンピューターの安定性が低下し、ネットワーク全体の安定性が低下する可能性があります。

  • サーバーサイドのセキュリティ: Office アプリケーションは、サーバーサイドで使用するように設計されていません。 そのため、Office アプリケーションは、配布されたコンポーネントで発生するセキュリティの問題を考慮していません。 Office は受信要求を認証しません。 また、サーバーサイド コードから、予期しないマクロの実行や、マクロを実行する可能性がある他のサーバーの起動を阻止する機能もありません。 匿名 Web サイトからサーバーにアップロードされたファイルを開かないでください。 サーバーは、最後に設定されたセキュリティ設定に基づいて、完全な特権を持つ管理者またはシステム コンテキストでマクロを実行できるため、ネットワークが侵害される可能性があります。 また、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 つのメインの問題の結果として発生します。 

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

Microsoft では、サーバー側ソリューションを開発する必要がある場合は、開発者が Office の Automation の代替手段を見つけることを強くお勧めします。 Office の設計に制限があるため、Office 構成の変更ですべての問題を解決するには十分ではありません。 Microsoft では、Office をサーバー側にインストールする必要のない、最も一般的なタスクを自動化よりも効率的かつ迅速に実行できる、いくつかの代替手段を強くお勧めします。 Office をプロジェクトのサーバー側コンポーネントとして関与する前に、代替案を検討してください。

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

Open XML ファイル形式はパブリック標準です。 


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

OPEN XML SDK のドキュメント

方法: Office Open XML 形式のドキュメントを操作する

Open XML オブジェクト モデルを使用した 2007 Word ファイルの操作 (パート 1/3)

Open XML オブジェクト モデルWord 2007 ファイルの操作 (パート 2/3)

Open XML オブジェクト モデルを使用した 2007 Word ファイルの操作 (パート 3/3)

Open XML オブジェクト モデルを使用した Excel 2007 および PowerPoint 2007 ファイルの操作 (パート 1/2)

Open XML オブジェクト モデルを使用した Excel 2007 および PowerPoint 2007 ファイルの操作 (パート 2/2)

Open XML オブジェクト モデル Server-Side 使用したドキュメント生成ソリューションの構築 (パート 1/2)

Open XML オブジェクト モデル Server-Side 使用したドキュメント生成ソリューションの構築 (パート 2/2)

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

HTTP コンテンツ ストリーミング用の Office 2007 ファイル形式 MIME の種類

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

これらのトピックの詳細と実装方法を示す例については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示してください。

198703 クライアント側 VBScript から Excel を自動化する方法

ASP から ADO を使用して Excel データのクエリと更新を行う方法

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 は現在、このような機能の提供に取り組んでおり、Microsoft Excel Servicesでこの機能の初期バージョンを提供しています。

Excel Servicesは、Microsoft Office SharePoint Server 2007 に含まれており、Office SharePoint Server 2007 で Excel ブックを読み込み、計算、表示できる新しいサーバー テクノロジです。 Excel Servicesの詳細については、次の Microsoft Developer Network (MSDN) Web サイトを参照してください。

Excel Servicesの概要

チュートリアル: Excel Web サービスを使用したカスタム アプリケーションの開発

Excel Servicesおよび Office Open XML 形式を使用したビジネス アプリケーションの作成 Word Automation Services は、SharePoint Server 2010 の新しいサービス アプリケーションです。 Word Automation Services は、文書を Microsoft Word クライアントでサポートされている形式に自動的にサーバーサイドで変換します。

Word Automation Services の概要

Word Automation Services の概要 この資料に記載されているどの方法がニーズを満たし、ソリューション展開に最適化かを評価する必要があります。 この資料で説明した内容によって、すべてのクライアントのあらゆる問題が解決されるかどうかは保証されません。 ソリューションを十分にテストしてから展開してください。

ヘルプを表示

その他のオプションが必要ですか?

サブスクリプションの特典の参照、トレーニング コースの閲覧、デバイスのセキュリティ保護方法などについて説明します。

コミュニティは、質問をしたり質問の答えを得たり、フィードバックを提供したり、豊富な知識を持つ専門家の意見を聞いたりするのに役立ちます。

この情報は役に立ちましたか?

言語の品質にどの程度満足していますか?
どのような要因がお客様の操作性に影響しましたか?
[送信] を押すと、Microsoft の製品とサービスの改善にフィードバックが使用されます。 IT 管理者はこのデータを収集できます。 プライバシーに関する声明。

フィードバックをいただき、ありがとうございます。

×