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

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

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

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

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

重要

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

対話型 UI 要素

Office アプリケーションは、対話型で実行されていることを前提としています。 予期しないエラーが発生した場合、または関数を完了するために指定されていないパラメーターが必要な場合、Office は、ユーザーに続行方法を求めるダイアログ ボックスをユーザーに求める目的で設計されています。 無人オートメーションでは、この入力を受け取るまでアプリケーションが停止すると、アプリケーションが "ハング" しているように見える可能性があります。 パブリック API を使用して Office を自動化する場合は、 Application.DisplayAlertsApplication.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 の詳細と、それを使用してユーザーのデータを操作する方法については、次のページを参照してください。

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 ファイルを作成または編集する方法の詳細については、次のページを参照してください。