無人 RPA 環境での Microsoft 365 での Office の無人自動化に関する考慮事項

  • [アーティクル]

無人 RPA 用の Microsoft 365 には、ユーザーが存在しない Office の自動化を可能にするライセンスが用意されていますが、現在のすべてのバージョンの Office は、アプリケーションのインターフェイスと対話するために、クライアント ワークステーションでエンド ユーザー製品として実行するように設計およびテストされています。 ユーザーが存在しないアプリケーションの使用に起因する予期しない動作は、欠陥ではありません。 この構成で Office を実行する場合は、アプリケーション ロジックでこれらの予期しない動作を考慮する準備が必要です。

この記事では、この方法を使用する場合に役立つ Office の無人自動化に関する考慮事項の一部について説明します。 ただし、この構成での Office の使用は厳密には "AS IS" であり、これらの予期しない動作を考慮する必要があることに注意してください。 ここで提供される情報は網羅的ではなく、すべてのクライアントのすべての問題を解決するとは限りません。 デプロイする前に、ソリューションを徹底的にテストすることをお勧めします。

無人オートメーションの一般的な問題

ユーザーが存在せずに Office を使用する場合は、Office の動作が想定とは異なる次の領域に注意してください。 ソリューションを正常に実行するには、これらの問題に対処し、その効果をできるだけ最小限に抑える必要があります。 アプリケーションをビルドするときは、これらの問題を慎重に検討してください。

重要

Microsoft では、無人の非対話型クライアント アプリケーションまたはコンポーネント (ASP、ASP.NET、DCOM、NT Services を含む) からの Microsoft Office アプリケーションの自動化は現在推奨されておらず、サポートされていません。この環境で Office を実行すると、Office が不安定な動作やデッドロックを発生する可能性があるためです。 詳細については、「Office の サーバー側オートメーションに関する考慮事項」を参照してください。

対話型 UI 要素

Office アプリケーションは、対話形式で実行されていることを前提としています。 予期しないエラーが発生した場合、または関数を完了するために指定されていないパラメーターが必要な場合、Office はユーザーに続行方法を尋ねるダイアログ ボックスをユーザーに求めるメッセージを表示するように設計されています。 無人オートメーションでは、この入力を受け取るまでアプリケーションが停止すると、アプリケーションが "ハング" しているように見える可能性があります。 パブリック API を使用して Office を自動化する場合は、 Application.DisplayAlerts や Application.AutomationSecurity などのプロパティを適切に構成することで、これらのアラートの多くを抑制できます。 コードは、ブロック中のアラートをいつでも識別して処理するように設計する必要があります。

ユーザー ID

Office アプリケーションでは、アプリケーションが自動化によって開始された場合でも、アプリケーションの実行時にユーザー ID が必要です。 このユーザー ID は、次のいずれかまたはすべてを引き起こす可能性があります。

  • 処理する必要がある追加のサインイン UI が存在します。
  • ユーザーごとのアクセス許可に基づいて開いたり編集したりできないファイル。
  • ファイルのメタデータに対する予期しない変更 (たとえば、特定のファイル プロパティは、自動化されたアプリケーション インスタンスのユーザー ID の ID に基づいて更新されます)。

さまざまなアプローチは、これらの問題を軽減するのに役立ちます。たとえば、 ドキュメント インスペクター を実行してメタデータを削除します。 シナリオに基づいて、これらのアプローチが適切かどうかを検討します。

サーバー側のセキュリティ

Office を無人で実行し、任意のファイル コンテンツを処理する場合、その環境に固有の追加の保護を使用して、それらのファイルに格納されているマクロの読み込みと実行を防ぐことができます。 Office は、コードから意図せずにマクロを実行したり、マクロを実行する可能性のある別のサーバーを起動したりしないように保護しません。 Application.AutomationSecurity などのプロパティを使用してこのリスクを軽減できますが、信頼できるコンテンツのみを読み込んでいるようにする必要があります。

さらに、Office では、クライアント認証情報をキャッシュして処理を高速化できる多くのコンポーネント (Simple MAPI、WinInet、MSDAIPP など) が使用されます。 Office がサーバー側で自動化され、複数のファイルを処理している場合、そのセッションの認証情報がキャッシュされている場合、あるクライアントは別のクライアントのキャッシュされた資格情報を使用できます。 そのため、クライアントは、他のユーザーを偽装することで、付与されていないアクセス許可を取得できます。

UI の変更

Office の UI 要素は大きく安定していますが、UI 要素の特定の場所は保証されておらず、製品の設計が進化してユーザーのフィードバックを組み込み、顧客のニーズを満たすように変更される可能性があります。 自動化のロジックは、これを考慮する必要があります。 これらの変更により、ボタンまたはグループ タブの名前付けの変更、タブ間のコマンドの移動、新しいタブの追加、または機能廃止ポリシーに合わせてコマンドが削除される可能性があります。 これらの変更は、UI とアプリケーションによって提供されるアクセシビリティ情報内で行うことができます。その情報は、ユーザービリティを向上させ、継続的な顧客フィードバックを考慮するように変更され、異なる時間に異なるユーザーに対してロールアウトされる可能性があります。

製品の変更がなくても、システム環境 (画面サイズ、解像度、DPI など) の違いにより、画面上の項目の場所が変更される可能性があります。 ユーザー入力をシミュレートするために画面座標に依存するアプローチでは、これらの変更を考慮し、それに応じて適応する必要があります。

シングル スレッド

Office アプリケーションは、1 つのクライアントに多様でリソースを集中的に使用する機能を提供するように設計された、再入不可の STA ベースのアプリケーションです。 アプリケーションは、メモリ マップされたファイル、グローバル アドインまたはテンプレート、共有オートメーション サーバーなどのグローバル リソースを使用します。 これにより、同時に実行できるインスタンスの数が制限され、アプリケーションがマルチクライアント環境で構成されている場合に競合状態になる可能性があります。 Office アプリケーションの複数のインスタンスを実行する場合は、結果として得られるソリューションの安定性を確保するために、それらを仮想マシン レベルで分離することを計画する必要があります。

回復性と安定性

上記の考慮事項でも、アプリケーションがユーザー入力をシミュレートする方法で自動化されている場合、または対話型の使用を大幅に超えるセッション長の場合は、対話形式で実行するときに存在しない問題が発生する可能性があります。 このコンテキストで Office を利用するソリューションでは、必要に応じて、アプリケーションの状態を監視し、それらを再起動するメカニズム (またはそれらが実行されている仮想マシン) を事前に構築する必要があります。

推奨される代替案

Microsoft では、Office をインストールしてサーバー側で実行する必要のないいくつかの代替手段を強くお勧めします。この構成では、自動化よりも一般的なタスクをより効率的かつ迅速に実行できます。 Office をプロジェクトのサーバー側コンポーネントとして関与する前に、代替案を検討してください。

Microsoft Graph

Microsoft Graph APIは、ユーザーのメール/予定表/連絡先/ファイルへのアクセス、ドキュメント変換、Excel ブックの計算など、無人自動化のニーズをサポートする多くのサービスを含む、Microsoft クラウドの一部としてユーザーとソリューションが利用できるサービス、データ、インテリジェンスへのアクセスを提供します。 これらのサービスは、無人で使用され、大規模なアクセス用に設計されており、標準の RESTful API 構文を利用します。 Microsoft Graph の詳細と、それを使用してユーザーのデータを操作する方法については、次のページを参照してください。

OPEN XML ファイル形式

多くの自動化タスクには、ドキュメントの作成または編集が含まれます。 Office では、ISO 29500 国際標準で定義されている標準 XML および ZIP テクノロジを使用して、開発者がファイル コンテンツを作成、編集、読み取り、変換できる Open XML ファイル形式がサポートされています。 これらのファイル形式は、Microsoft .NET 3.x Framework の System.IO.Package.IO 名前空間など、あらゆる ZIP/XML ツールを使用して操作できます。 ファイル形式の直接編集は、サービスから Office ファイルへの変更を処理するための推奨およびサポートされる方法です。

Microsoft は、.NET 3.x Framework から Open XML ファイル形式を操作するための SDK を提供します。 SDK の詳細と、SDK を使用して Open XML ファイルを作成または編集する方法については、次を参照してください。