• [アーティクル]

Office 2010 アプリケーション互換性ガイド

 

適用先: Office 2010

トピックの最終更新日: 2017-01-17

Microsoft Office 2010 の展開におけるアプリケーションの互換性テストと修復プロセスでは、互換性の問題が特定されるため、その問題を解決するための計画を容易に作成できます。この情報は、主に、アプリケーションの互換性の問題の評価と緩和を行う IT 担当者に役立ちます。またこの情報は、Office アプリケーションをアップグレードする開発者にも役立つ場合があります。管理者および開発者は、ここで説明する手順を完了することで、Office と連係するアドインとアプリケーションの種類、およびそれらを Office 2010 に移行する方法についての理解が深まります。

ここでは、ドキュメントの互換性、変換、および移行については説明しません。レガシ Office ファイルを変換し、互換モードを使用する方法については、「Office 2010 のドキュメントの互換性」を参照してください。

この記事の内容

  • Office 2010 でのアプリケーションの互換性の概要

  • アプリケーションの互換性評価と修復プロセス

  • 互換性テストの計画

  • 環境の評価

  • 互換性の問題のテストと修復

Office 2010 でのアプリケーションの互換性の概要

開発者および熟練ユーザーは、初期の Office 製品の登場以来、Office を拡張するためのコードを作成してきました。Office が徐々に進化し、機能の変更、機能の削除、およびファイル形式の変更が行われてきた結果、古いアドインやカスタマイズを Office 2010 で使用した場合に正常に動作しない可能性が出てきました。もちろん、10 年以上前の Office ファイルを使用している組織にとっても、アプリケーションの互換性というトピックは難題になることがあります。

Office 2010 では、製品にさまざまな改良や変更が加えられており、既存のファイル、マクロ、アドイン、および Microsoft Visual Studio ソリューションの互換性に影響する場合があります。このような変更の一部を次に示します。

  • 削除された機能   Office 2010 から削除された機能 (およびそれに対応するオブジェクト モデル) への依存関係があるアドインおよびアプリケーションは正常に動作しなくなる可能性があります。

  • 機能の変更   機能 (およびそれに対応するオブジェクト モデル) が更新されている場合、アドインおよびアプリケーションが予期したとおりに動作しない可能性があります。このような変化は、明白な場合もあれば、詳細なテストを経て初めて判明する場合もあります。

  • 64 ビットでの非互換性   Office 2010 には 32 ビット版と 64 ビット版の両方があります。64 ビット版は、複雑な Microsoft Excel スプレッドシートや Microsoft Project ファイルを使用するときに多くのメモリ容量を必要とするユーザー向けです。64 ビット版の Office を展開する予定の場合は、32 ビットのクライアント コンピューター用に作成した ActiveX コントロール、アドイン、および Microsoft Visual Basic for Applications (VBA) ソリューションが 64 ビット版の Office 2010 で動作しない可能性があるという点を考慮する必要があります。

Office 2010 でのアプリケーションの互換性の問題を評価および修復するために、いくつかのツールとソリューションが提供されています。IT 管理者は、新しい Office Environment Assessment Tool (OEAT) を使用して、Office と連係するアドインおよびアプリケーションを識別できます。開発者は、新しい Microsoft Office 2010 Code Compatibility Inspector ツールを使用して追加的なテストを実行し、VBA プロジェクトまたは Visual Studio コードの中から、非互換の可能性があるコードを特定できます。アプリケーションを修正できない場合には、管理者はリモート デスクトップ サービス (ターミナル サービス)、並行インストール、新しい Microsoft Application Virtualization (App-V) などのソリューションを使用して、互換性のある古い Office 環境を Office 2010 と共存させて残すことができます。

Office 2010 のアプリケーション互換性評価ツールについての簡単な説明を次に示します。

Office Environment Assessment Tool (OEAT)   OEAT は、Office 2010 用の新しいスキャン ツールです。ユーザーのコンピューターにインストールされているアドインを特定できます。OEAT は、Microsoft Office 97、Microsoft Office 2000、Microsoft Office XP、Microsoft Office 2003、および 2007 Microsoft Office system 用のアドインの情報を収集および報告します。また OEAT は、見つかったサード パーティ製アドインのリストを、互換性のあるアドインのリストと比較します。互換性のあるアドインのリストは、独立系ソフトウェア ベンダー (ISV) のアプリケーション互換性可視化プログラム (Application Compatibility Visibility Program) で管理されています。

OEAT をダウンロードするには、「Office 2010 Tool: Office Environment Assessment Tool (英語)」(https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0x411) (英語) を参照してください。

ISV アプリケーション互換性可視化プログラム (Application Compatibility Visibility Program)   これは、独立系ソフトウェア ベンダー (ISV) の製品と Office 2010 との互換性について、ISV からの情報を記録しておく新しいプログラムです。ISV は、自社製品についての情報を特別な ISV ポータルから提出し、Microsoft はこのリストを「Microsoft Office 2010 の互換性 (リソース センター)」(https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0x411) に公開します。このリストは OEAT でも使用され、互換性がある既知のアドインが概要レポートで示されます。

このプログラムに参加している ISV の最新のリストを参照するには、「Microsoft Office 2010 の互換性」(https://go.microsoft.com/fwlink/?linkid=186766\&clcid=0x411) を参照してください。

Microsoft Office 2010 Code Compatibility Inspector (OCCI)   Microsoft Office 2010 Code Compatibility Inspector は、既存の VBA、Visual Basic .NET、および C# のソース コードを参照し、Office 2010 と互換性のないオブジェクト モデルの API 呼び出しを見つけます。このツールは、Microsoft Visual Basic for Applications 7.0 (VBA 7)、および Microsoft Visual Studio 2008 または Microsoft Visual Studio 2010 と連係し、基本的なスキャナーを含んでいます。このツールで Office 2010 と互換性のないコードが見つかると、コードにコメントが追加されます。開発者は後でこのコメントを参照して修正を加えることができます。またインスペクター ツールは、コード内の Declare ステートメントおよび ActiveX コントロールが使用する DLL 参照のうちで、64 ビット版の Office 2010 との互換性のために更新が必要な部分もスキャンします。

OCCI をダウンロードするには、「Office 2010 Tool: Compatibility Inspector (英語)」(https://go.microsoft.com/fwlink/?linkid=181874\&clcid=0x411) (英語) を参照してください。

次の表に、Office ベースのカスタマイズのうち、多くの組織で使用されている種類と、それぞれのカスタマイズの評価に使用するツールを示します。これらのカスタマイズの中には、以前のバージョンの Office で一般的に使用されていたものもあるため、詳細情報へのリンク先には、Office 2003 またはそれ以前のバージョン用の開発者向けドキュメントが多くあります。

カスタマイズの種類 説明 評価ツール

オートメーション アドイン (.xll または .wll)

オートメーション アドインでは、開発者が既存の Office 2010 アプリケーションの機能をカスタム アプリケーションに組み込むことができます。Office オートメーション アドインの例には、顧客の課金データを Microsoft Excel ワークシートに書き込む CRM アプリケーションがあります。

オートメーション アドインの詳細については、「Excel の COM アドインおよびオートメーション アドイン」(https://go.microsoft.com/fwlink/?linkid=186622&clcid=0x411) を参照してください。

OEAT

COM アドイン (Windows .dll)

COM アドインは、Microsoft Office 2000 の一部として導入されたもので、開発者が自ら選択したプログラミング言語および環境で Office ベースのソリューションを開発できます。作成した COM アドインは .dll ファイルとしてコンパイルされます。この .dll ファイルは 1 つまたは複数の Office アプリケーションで読み込むことができ、Office オブジェクト モデルと連係できます。

COM アドインの詳細については、「COM アドインについて」(https://go.microsoft.com/fwlink/?linkid=186623&clcid=0x411) を参照してください。

OEAT

Office 97–2003 形式の VBA アドイン (.dot, .wll, .xla, .xll, .ppa)

Office 2007–2010 形式の VBA アドイン (.dotm, .xlam, .ppam)

VBA テンプレート アドインは Microsoft Visual Basic for Applications (VBA) で作成されます。

VBA アドインの詳細については、「Office 2010 VBA の基礎知識」(https://go.microsoft.com/fwlink/?linkid=186624&clcid=0x411) を参照してください。Microsoft Word テンプレートとアドインの違いの詳細については、「Word 文書テンプレートと Word アドイン (全文書対象のテンプレート)」(https://go.microsoft.com/fwlink/?linkid=186625&clcid=0x411) を参照してください。

OEAT および OCCI

Office 2007–2010 形式の VBA マクロ有効ファイル (.docm, .xlsm, .pptm)

これらのファイルには VBA マクロ コードが含まれていますが、アドインとして保存されていません。

OEAT は、マクロ有効ファイル形式の Word ファイルと Excel ファイルのうち、スタートアップ フォルダーに保存されているもの、または全文書対象のテンプレートとして読み込まれるものを検出します。その他の場所に保存されているマクロ有効ファイルは、OEAT では検出されません。また、マクロ有効ファイル形式の PowerPoint ファイルについては、保存場所にかかわらず OEAT では検出されません。

マクロ有効ファイルの詳細については、「Office 2010 でサポートされるファイル形式」を参照してください。

OEAT および OCCI

Visual Studio で作成された Office アドイン

Visual Studio で作成された Office アドインを使用すると、組織が Office アプリケーションをカスタマイズし、ビジネス プロセスに必要な特定の機能を追加できます。

Visual Studio は、組織で使用できる次の 2 種類のソリューションをサポートします。

  • ドキュメントレベルのカスタマイズ   この種類のカスタマイズは、Microsoft Word または Microsoft Excel の単一のドキュメント、ブック、またはテンプレートと関連付けられた単一のアセンブリで構成されます。ドキュメントレベルのカスタマイズの機能を使用できるのは、該当するドキュメントを開いているときに限られます。この種類のカスタマイズでは、開いているドキュメントに関係なく新しいメニュー項目またはリボン タブを表示するなど、アプリケーション全体に変更を加えることはできません。

  • アプリケーションレベルのアドイン   この種類のアドインは、Office アプリケーションと関連付けられた単一のアセンブリで構成されます。このアドインからは、アプリケーションの自動化と拡張のためのオブジェクト モデルを呼び出すことができ、Microsoft .NET Framework の任意のクラスを使用できます。

OEAT はアプリケーションレベルのアドインのみの検出に使用できます。

Visual Studio で作成される Office アドインの詳細については、「Office ソリューションの開発の概要 (英語)」(https://go.microsoft.com/fwlink/?linkid=188380&clcid=0x411) (英語) を参照してください。

OEAT および OCCI

アプリケーションの互換性評価と修復プロセス

次の図に、アプリケーションの互換性評価と修復プロセスの概要を示します。この図に示す各タスクの詳細については、この記事の対応するセクションで説明します。

アプリケーション互換性プロセス

注意

ここでは、ドキュメントの互換性、変換、および移行については説明しません。レガシ Office ファイルを変換し、互換モードを使用する方法については、「Office 2010 のドキュメントの互換性>」を参照してください。

互換性テストの計画

アドインとアプリケーションの評価、修復、およびパイロットについて計画することは、アプリケーションの互換性テストのプロセス全体の中で重要な第 1 歩となります。以前実施した 2007 Office system の互換性テストの結果を使用できそうに思えても、使用はお勧めできません。展開の実施を遅らせる原因になります。

評価の計画

以下のセクションでは、計画のタスクについて説明します。これらは、組織で使用するアドインとアプリケーションの評価を準備するうえで役立ちます。

評価のドキュメントと結果を格納する一元的なリポジトリの作成

評価と修復プロセスを管理しやすくするために、発見されたアプリケーションとその状態について格納するための一元的なリポジトリを作成することをお勧めします。Microsoft SharePoint Server 2010 などのソリューションを使用すると、すべてのプロジェクト メンバーに最新情報を伝え、プロジェクト自体を円滑に進めることができます。

関係者の特定

関係者とは、プロジェクトに対してリソースの承認と割り当てを行う人またはグループです。計画プロセスの早い段階で関係者を特定しておくと、アプリケーションの互換性のプロジェクト チームは、強い権限を持つ人たちに対してプロジェクトの成果物を伝え、確認を受けることができます。

次の表に、アプリケーションの互換性プロジェクトにおける関係者の一般的な役割を示します。

役割 職務

アプリケーション所有者

以前のバージョンの Office を使用して行われていたビジネス プロセスが、アップグレード後も中断なく継続されることを確認します。

プロジェクト支援者

Office アップグレードの成功を支援し、組織内で積極的に告知します。

プロジェクト参加者への役割の割り当て

次の表に、アプリケーションの互換性プロジェクトでの必要性が考えられる役割とそれぞれの職務を示します。

役割 職務

プロジェクト マネージャー

プロジェクトのプロセス全体の確実な遂行を担い、全体のリソース、評価基準、およびリスクを管理します。

互換性検証テスター

テスト計画に従って、ファイル形式、マクロ、アドイン、Office オートメーションなど、Office コンポーネントに潜在的な互換性の問題がないかどうかをテストします。

OEAT オペレーター

OEAT のセットアップと構成を理解および実行します。

修復リーダー

Office のカスタマイズの互換性の問題を解決するための作業を実行します。

回帰テスター

Office オブジェクトに対して実施した修復が成功したかどうかを確認します。この役割は修復リーダーが担当することがよくあります。

ユーザー承諾テスター

関係する部署の代表者で、アプリケーションの修復が成功したことと、その他のカスタマイズや操作に影響していないことを確認します。この役割は、修復および回帰テストの担当者とは別の人にする必要があります。

ビジネス アナリストまたは所有者

部署にとって重要なアプリケーションとアドインのコードとドキュメントを管理します。

展開グループ リーダー

技術プロセス全体の進行状況を管理および追跡します。報告または管理作業の一部を委任する場合があります。

アプリケーション パッケージ化グループ

Office 2010 インストール パッケージを管理します。

クライアント (デスクトップ) チーム

System Center Configuration Manager (SCCM) など、組織の構成管理ツールによる Office 2010 パッケージの展開を管理します。

サービス デスク

テスター向け (移行の完了後はユーザー向け) に、Office の機能面のサポートを提供します。

部署の特定とインタビュー

評価の計画で次に行う手順は、組織内の部署またはグループを特定し、代表者にインタビューを行って、現在の業務処理に使用しているアドインを把握することです。各アドインの重要性、用途、作成された理由、機能、および作成者を把握しておくことは、アドインの修復方法や、問題が見つかったときに正しく修正する方法について的確に判断するうえで重要です。

Office アプリケーション用のアドインの中には、組織内で非公式に作成されたものが含まれている場合があります。したがって、その所有者とソース コード (存在する場合) を追跡するための調査が必要になることがあります。

次のフォームは、インタビューの質問のテンプレートとして使用できます。

アプリケーション情報

部署

アプリケーション名

アプリケーションの担当者/所有者

AppID

バージョン

優先度

層

Office 2010 の互換性チェックの合否 (判明している場合)

互換性の問題の説明 (判明している場合)

ユーザー数

アプリケーションが使用する Office のバージョン (XP、2003、2007、2010 など)

用途の説明 (たとえば、Office ドキュメントのエクスポート、Office アプリケーションのアドインなど)

アプリケーションが使用する Office スイートのコンポーネント

Word

Excel

Access

PowerPoint

その他

このアプリケーションは複雑な Office オブジェクト (グラフ、ピボットテーブル レポート、図) を使用しているかどうか

データ入力アプリケーションまたはフロントエンド アプリケーションかどうか。その場合は詳細を記述

アプリケーションがサポートする言語

スキャンするクライアント コンピューターの特定

クライアント コンピューターのスキャンが必要な部署を特定したら、各部署のクライアント コンピューターについて、統計的に意味のあるサンプリングを特定するプロセスを開始できます。組織内のすべてのクライアント コンピューターをスキャンする必要はありません。しかし、組織の規模に応じて、場合によっては、環境全体またはグループまたは組織単位 (OU) 全体をスキャンする方が、対象となるクライアント コンピューターを別個に定めるよりも制約が少ない (または簡単な) ことがあります。20% までの範囲で統計的に意味のあるサンプリングを行えば、Office 2010 環境での互換性の問題を的確に評価および修復するための十分な情報が得られます。

重要

OEAT を実行するすべてのクライアント コンピューターに Microsoft .NET Framework 2.0 以降がインストールされている必要があります。OEAT の要件の詳細については、「Office Environment Assessment Tool (OEAT) ユーザー ガイド (Office 2010 用)」を参照してください。

組織に最新のクライアント インベントリがない場合には、Microsoft Assessment and Planning (MAP) Toolkit を使用してクライアント インベントリを生成し、Office 2010 の対応状況を評価することを検討します。このインベントリを使用し、ビジネス グループのリーダーと協力して、OEAT による評価の対象とするクライアント コンピューターを選択できます。MAP Toolkit の詳細については、「Microsoft Assessment and Planning Toolkit (英語)」(https://go.microsoft.com/fwlink/?linkid=149448\&clcid=0x411) (英語) を参照してください。

修復の計画

以下のセクションは、互換性のないアプリケーションを分類および修復するための基準条件を確立するうえで役立ちます。計画プロセスの早い段階で統一した条件を定めておくと、評価とテストの結果が出てからの不一致やその他の遅れを回避するうえで有用です。

アプリケーションの分類と優先順位付けの方法の判断

企業では、Office ベースのさまざまなアプリケーションやアドインを開発、展開、および保守しており、組織にとっての価値はそれぞれ大きく異なることがあります。したがって、ビジネスにとって各アプリケーションが持つ価値に基づいて、アプリケーションを種類や層ごとに分類することが重要です。簡単な分類方法としては、各アプリケーションがミッション クリティカルかどうかに応じた分類があります。その他の分類方法の例を以下に示します。

  • 社内のアプリケーションとサード パーティ アプリケーション

  • 部署のアプリケーション

  • 管理していないソリューション (エンドユーザーが作成したテンプレート、アドイン、マクロなど)

  • アプリケーションのユーザー数

  • 役員が使用するアプリケーションかどうか

  • アプリケーションの想定利用期間

次の表は、組織が持つさまざまな種類の Office カスタマイズの分類および優先順位付けの例です。

カスタマイズ ミッション クリティカル 非ミッション クリティカル

オートメーション アドイン

予防的な OEAT スキャン、テスト、および修復

見つかったユーザーに対応

COM アドイン

予防的な OEAT スキャン、テスト、および修復

見つかったユーザーに対応

VBA アドイン

予防的な OEAT スキャン、テスト、および修復

見つかったユーザーに対応

ミッション クリティカルなアプリケーションの優先順位付けをさらに進めるために、第 1 層、第 2 層、第 3 層という分類を行うことができます。各層の分類方法の例を以下に示します。

  • 第 1 層: ミッション クリティカル   ミッション クリティカルなアプリケーションを使用できなくなった場合、ビジネス継続性や組織の収益にとって打撃となります。役員が使用するアプリケーションは、アプリケーションのユーザー数やビジネス上の優先順位に関係なく、ミッション クリティカルとみなす必要があります。この層には、組織のユーザーの 10% 以上が使用するアプリケーションも含まれます。

  • 第 2 層: ビジネス クリティカル   これらは、ビジネス クリティカルなアプリケーション、または組織のユーザーの 10% 以上が使用しているアプリケーションです。この層には、ビジネスの優先順位に関係なく、組織のユーザーの 1 ～ 10% が使用しているアプリケーションも含まれます。これらは、ミッション クリティカルなアプリケーションや収益に影響するアプリケーションではありません。しかし、生産性に影響をもたらし、経費の増加や収益の減少を間接的に引き起こす可能性があります。

  • 第 3 層: ビジネス アプリケーション   これらのアプリケーションは、ミッション クリティカルではなく、影響する社員が 10 人程度または組織全体の 1% 以下です。これらは、通常は小規模な作業を支援するツールで、ビジネスへの影響は大きくありません。

修復の方針の決定

アプリケーションを分類するための条件を定めたら、考えられる修復の方針を決定する必要があります。実際の修復作業を計画することは簡単ではありませんが、カスタマイズの種類ごとに、問題解決の筋道となる全般的な方針を確立することはできます。次の表に、アプリケーションの種類と想定利用期間に基づく推奨の修復の方針を示します。

種類 考えられる方針

利用期間が限られている社内アプリケーション

そのアプリケーションの利用をやめ、別の手順を探します。

利用期間が長い社内アプリケーション

新しいオブジェクト モデルに適合するようにコードの書き直しまたは再作成を行います。

利用期間が限られているサード パーティ アプリケーション

そのアプリケーションの利用をやめ、別の手順を探します。

利用期間が長いサード パーティ アプリケーション

更新または代替品についてベンダーに問い合わせます。

動作していないアプリケーション

新しいディレクトリ構造でアプリケーションを再インストールするか、そのアプリケーション用の仮想環境を作成します。

アプリケーションの修復を進める中で、アプリケーションの優先順位が最初の評価とは変化する場合があります。修復の評価には厳密な手順を定め、アプリケーションの優先順位を上の層に移動する変更のみ認めるようにします (下への移動は認めません)。Microsoft の IT 部門が行ったアプリケーションの分類と優先順位付けの方法の詳細については、「Deploying the 2007 Office System at Microsoft (英語)」(https://go.microsoft.com/fwlink/?linkid=178278\&clcid=0x411) (英語) を参照してください。

また Microsoft は、Office のカスタマイズを移行するときに発生する既知の問題についての情報を TechNet で公開しています。詳細については、「Office 2010 での製品と機能の変更」を参照してください。Microsoft のパートナーの中にも、修復プロセスを支援するツールを用意している所があります。

パイロットの計画

プロジェクト チームは、アドインおよびアプリケーションのパイロットの方法について検討する必要があります。具体的には、以下の点について判断します。

  • どのユーザーがパイロットに参加しますか。

  • パイロットに参加したユーザーは問題をどのように報告しますか。

  • ヘルプデスクの社員はパイロットをサポートしますか。その場合、それらの社員をどのようにトレーニングしますか。

  • パイロットをいつ開始しますか。たとえば、組織によっては、プロセスを進める中で初期フィードバックを得るために、計画段階の早い時点でパイロット テストを開始する所があります。

パイロットを計画するうえで参考になるリソースを以下に示します。これらのリソースは、Office 2010 の互換性テストに限定した内容ではありません。しかし、これらのリソースで説明されている原則の多くはそのまま該当します。

環境の評価

評価段階では、統計的に意味のあるクライアント コンピューターのサブセットに対して OEAT を実行して、アドインとアプリケーションのインベントリを収集します。結果の分析とアプリケーションの優先順位付けを行うと、テストと修復段階に移ることができます。

OEAT の実行

OEAT は、ネットワーク共有からでも、ユーザーに配布する形でも実行できます。OEAT はクライアント コンピューターをスキャンし、スキャン結果を所定の場所 (通常はネットワーク共有) に保存します。スキャンが完了したら、OEAT を使用して結果を Microsoft Excel のスプレッドシートに集計でき、そのシートを修復プロセスで使用できます。

使用する環境に応じて、OEAT は次のいずれかの方法で展開できます。

  • Active Directory 環境   Active Directory ログイン スクリプトを使用して OEAT を展開します。ユーザーがログインすると OEAT が自動的に実行され、所定の場所に結果が保存されます。

  • 管理された環境   Systems Management Server (SMS)、System Center Configuration Manager (SCCM) などの管理ソリューションを使用して OEAT を展開します。

  • 管理または一元化されていない IT 環境   OEAT 用の共有を作成し、手動でスキャンを実行する方法をユーザーに指示します。

OEAT を展開および使用する方法の詳細については、「Office Environment Assessment Tool (OEAT) ユーザー ガイド (Office 2010 用)」を参照してください。OEAT をダウンロードするには、「Office 2010 Tool: Office Environment Assessment Tool (英語)」(https://go.microsoft.com/fwlink/?linkid=171092\&clcid=0x411) (英語) を参照してください。

OEAT の結果のレビュー

クライアント コンピューターのスキャンが完了したら、OEAT の [Compile results] オプションを使用して、スキャンしたすべてのクライアント コンピューターの結果をまとめたスプレッドシートを作成します。スプレッドシートは、以下のような複数のワークシートで構成されます。

  • [SummaryReport]   このワークシートには、スキャンしたクライアント コンピューターを Office 2010 に移行できるかどうかを判断するうえで役立つ概要情報が記載されています。このワークシートには、平均空き容量、プロセッサ、コンピューターの製造元、インストールされている Windows (Service Pack のレベルを含む)、およびインストールされている Office についてのデータがあります。ここで得られるデータは、構成管理という観点からも興味の対象となります。クライアント コンピューターで使用している Office や Windows のバージョンが想定と異なる場合があるからです。

  • [MicrosoftOfficeAddins]   このワークシートには、Office に含まれているすべてのアドインのリストが記載されています。

  • [AddinsNotShippedWithOffice]   このワークシートには、Office に含まれていないすべてのアドインのリストが記載されています。評価と計画の基になるのは主にこのレポートです。アプリケーションごとのリストの並べ替え、最後にアクセスまたは変更した日付の確認、アドインが検出されたクライアント コンピューターの数の確認を行うことができます。また、同じアドインのバージョン番号を比較して、最新の状態に維持されていないクライアント コンピューターがないかどうかを判断できます。そのようなコンピューターがある場合、組織の構成管理プロセスに問題がある可能性があります。

[AddinsNotShippedWithOffice] ワークシートで、まず [Compatibility] 列から、各アドインの互換性の状態を確認します。OEAT は、発見したアドインを、互換性のあるアドインのリスト (ISV の互換性プログラムによって把握されているリスト) に照らし合わせて、この列のデータを生成します。互換性の状態の結果には以下があります。

  • [UNKNOWN]   現在このアドインは、Office 2010 と互換性があるアドインとして Microsoft のベンダーが公表したリストには入っていません。したがって、このアドインの状態は不明です。OEAT が使用できるベンダー データが更新されると、この状態は変更される可能性があります。スプレッドシートを集計するときに、新しいベンダー データをダウンロードできます。

  • [PARTIAL MATCH]   OEAT がこの状態を通知するケースは 2 つあります。1 つは、一致するベンダー名のみが見つかった場合です。もう 1 つは、一致するベンダー名と製品名が見つかったが、バージョン番号が一致しない場合です。[URL] 列に示されているリンクを使用してベンダー リストを参照し、同じベンダーのアドインで互換性があるものを確認できます。

  • [EXACT MATCH]   この状態が示されるのは、ベンダー名と製品名が一致し、アドインのバージョン番号が、ベンダーが公表したバージョン番号と同じかそれ以降である場合です。

重要

OEAT の正式版を使用している場合で、互換性データのダウンロードを行わないよう確認メッセージで選択したとき、または OEAT のベータ版を使用している場合には、[Compatibility] 列は表示されません。OEAT の正式版は「Microsoft ダウンロード センター (英語)」からダウンロードできます。

修復計画の確定

ここまで来ると、OEAT の結果を、計画段階で定めた優先順位付けの条件に照らして対応付けることができます。この作業のスケジュールを決めるときには、部署のインタビューの時点で判明しなかったアドインの調査と優先順位付けを行えるような時間の余裕を見ておく必要があります。VBA アドインおよび Visual Studio アドインの非互換の程度を把握するために、開発チームはこの段階で OCCI を実行して、基になるコードにどの程度の変更が必要かを把握できます。

互換性の問題のテストと修復

この段階では、開発チームと共に、ミッション クリティカルおよび優先順位が高いアドインとアプリケーションのテストを開始し、Office 2010 での互換性の問題を具体的に発見します。互換性の問題が特定されたら、開発チームは、計画段階で行った作業に基づいて、互換性のないアドインおよびアプリケーションの修復に取りかかります。

複数のアプリケーションおよびアドインを修復するときには、これらの修復が一度に解決するとは限りません。すべての修復をまとめてテストしたうえで、現実のシナリオでこれらのパイロットを行う必要があります。修復の検証では、1 つ 1 つの手順が重要です。Office 2010 の展開全体の安定化につながり、ひいては移行の成功度を高めることになります。

アドインとアプリケーションのテスト

以下のフローチャートは、Office 2010 との非互換性を特定するためにさまざまな種類のアプリケーションをテストする開発者向けに、全体の概要を示したものです。詳細については、以下を参照してください。

全般的なアプリケーション テスト

次のフローチャートは、アプリケーション テストの概要を示します。以下、このセクションのフローチャートでは、アドイン、マクロとスクリプト、Office オートメーションなど、Office アプリケーションの種類ごとのテスト プロセスを示します。

アプリケーション テストのフローチャート

Office アドインのテスト

Office アドイン テストのフローチャート

マクロとスクリプトのテスト

マクロ テストのフローチャート

Office オートメーションのテスト

Office 自動テストのフローチャート

Office Code Compatibility Inspector ツールの実行

開発者は、全般的なテストの一環として OCCI ツールを実行できます。OCCI では、オブジェクト モデルのメンバーに加えられた既知の変更や廃止をスキャンできます。また、64 ビット版の Office 2010 との互換性のために更新が必要な ActiveX コントロールに関して、それらが使用する VBA の Declare ステートメントや DLL 参照もスキャンされます。互換性の問題となり得る点が見つかった場合、その問題について開発者の注意を促すために、OCCI はコードにコメントを追加します。

OCCI のスキャンが完了するごとに、プロジェクトで発見された内容について、概要と詳細のレポートが示されます。スキャンされる項目には以下が含まれます。

  • 変更   構文に変更が加えられたオブジェクト モデルのメンバーを検出します。OCCI は、Office 97 以降に変更されたオブジェクト モデルのメンバーの使用を検出します。

  • 廃止   廃止されたオブジェクト モデルのメンバーが使用されている部分を検出します。OCCI は、Office 97 以降に廃止されたオブジェクト モデルのメンバーの使用を検出します。

OCCI の使用方法については「Microsoft Office Code Compatibility Inspector ユーザー ガイド」を参照してください。以前のバージョンの Office 以降に加えられたオブジェクト モデルの変更に関する詳細など、アプリケーション固有の開発リソースについては、「Microsoft Office 2010」(https://go.microsoft.com/fwlink/?linkid=206197\&clcid=0x411) を参照してください。

アドインとアプリケーションの修復

Office 2010 との互換性の問題があるアプリケーションまたはアドインを修正するには、複数の方法があります。以下のセクションで、修復方法の選択肢について簡単に説明します。

ベンダーからの更新版の入手

OEAT のレポートでは、互換性があることが確認されているアドインへのリンクが示されます。しかしアプリケーションによっては、このリストに記載されていないこともあります。その場合は、ベンダーに直接問い合わせる必要があります。移行までの間に更新版のアドインを入手できない場合、またはアドインが更新されない (またはベンダーが既に事業を行っていない) 場合には、一時的な回避策の開発が必要になります。一時的な回避策を使用できない場合は、仮想化または並行インストールの使用を検討します。

社内アプリケーションの更新

ソース コードがあり、アドインまたはアプリケーションの機能を理解できる場合、または、ドキュメントがあり、元の開発チームが引き続き活動中で相談できる場合には、社内アプリケーションの更新には理想的な状況です。OCCI を使用すると、ソース コード内で互換性のない機能を特定でき、社内アプリケーションの更新のプロセスが大きく簡素化されます。その場合も、必要な修正は開発チームが自ら行う必要がありますが、OCCI を使用する方が、互換性のないコードの特定ははるかに簡単です。

注意

社内アプリケーションの作成プラットフォームが非常に古い場合 (たとえば Visual Basic 6 またはそれ以前のバージョンの場合), .NET Framework を使用してツールを完全に作成し直すことをお勧めします。

社内アプリケーションを更新する必要がある開発者は、以下の説明を参考にしてください。

Visual Studio で作成したアドイン

Office 2010 のランタイム コンポーネントは、Microsoft Visual Studio Tools for Applications (VSTA) および Visual Studio 2008 .NET のアドイン、ドキュメント ソリューション、およびスプレッドシート ソリューションがすべて 64 ビット版の Office 2010 でも動作するように作成されています。これらのランタイム コンポーネントは Office 2010 と共にインストールされます。したがって管理者は、このランタイムのために別個のインストールを含める必要はありません。しかし、その他の面で考慮が必要な点があります。

Visual Studio プロジェクトでは、[Any CPU] オプションを使用した場合に、C# または Visual Basic のコードを Microsoft Intermediate Language (MSIL) にコンパイルできます。実行時には、MSIL は、AMD、Intel 32 ビット、または同 64 ビットの正しいチップ セット向けに Just In Time (JIT) でコンパイルされます。しかしこの技術は, .NET Framework のバージョン 1.0 および 1.1 では適用されません。これらのバージョンでは、この 64 ビット変換は有効になりません。

仕様に準拠している .NET Framework 2.0 コードであっても見直しは必要です。コードでプロセス呼び出し (p/invoke) を使用している場合、これはネイティブ (プロセッサのアーキテクチャに固有) となるからです。p/invoke を使用してネイティブ API メソッドを呼び出すと、64 ビット版の Office 2010 で正常に動作している VSTO ソリューションで問題が生じる可能性があります。

コードで Win32 API を意図的に呼び出しており、そのシグネチャ (メソッド名、パラメーター リスト、および DLL 名) が、対応する Win64 API と厳密に一致しない場合、問題が生じる可能性があります。これは、Office ソリューションか Windows ベースのソリューションかに関係なく、すべてのソリューションに共通しています。

64 ビット版の Office 2010 用のソリューションを作成する方法の詳細については、MSDN 技術ライブラリの Visual Studio 2005 の 64 ビット アプリケーション (https://go.microsoft.com/fwlink/?linkid=178279\&clcid=0x411) および Visual Studio 2010 の 64 ビット アプリケーション (英語) (https://go.microsoft.com/fwlink/?linkid=152431\&clcid=0x411) (英語) を参照してください。

VBA ソリューションとマクロ

Visual Basic for Applications (VBA) で作成されたソリューションとマクロは、Office 2010 のオブジェクト モデルを使用している限りは正しく動作します。ただし、一部の呼び出しが廃止されて動作しなくなる場合もあります。VBA コードで Windows API 呼び出しを使用している場合、これらの呼び出しは 32 ビット DLL である可能性が大です。簡単な修正方法としては、Declare ステートメントで PtrSafe キーワードを使用するようにコードを更新する方法があります。このような Declare ステートメントは OCCI で特定できます。VBA の 64 ビット互換性の詳細については、「Office 2010 の 32 ビット バージョンと 64 ビット バージョンとの互換性」(https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0x411) を参照してください。

ActiveX コントロール

ActiveX コントロールのうち、ネイティブな 32 ビット コントロールは、64 ビット版の Office 2010 ではサポートされていません (2007 Office system および以前のバージョンの Office と互換性があるコントロールのほとんどが該当するものと考えられます)。このようなコントロールを修復するには、再コンパイルを行うか (ソース コードを入手できる場合)、ベンダーによる更新を依頼または待機するか、または仮想化の手法を使用する必要があります。VBA の 64 ビット互換性の詳細については、「Office 2010 の 32 ビット バージョンと 64 ビット バージョンとの互換性」(https://go.microsoft.com/fwlink/?linkid=186639\&clcid=0x411) を参照してください。

Outlook アプリケーション

Outlook 2013 では、アドイン用の新しい高速シャットダウン プロセスが適用されます。新しいシャットダウン プロセスでは、ユーザーが Outlook を終了した後もリソースが継続的に保持されることで、アドインによって長時間の遅延が発生することが回避されます。この変更は一部の既存のアドインに悪影響を与える可能性がありますが、アドイン ベンダーと IT 管理者は、標準のアドイン シャットダウン プロセスに戻すように Outlook を強制することでその影響を解決できます。新しいシャットダウン プロセスの詳細については、「Outlook 2010 でのシャットダウンの変更」(https://go.microsoft.com/fwlink/?linkid=203255\&clcid=0x411) を参照してください。

Exchange クライアント拡張機能 (ECE) は Outlook 2013 に読み込まれません。アーカイブ ソリューション、セキュリティ ソリューションなど、一部のサード パーティ アプリケーションは、ECE を使用しているため、Outlook 2013 用に更新する必要があります。詳細については、「Announcing the deprecation of Exchange Client Extensions (英語)」(https://go.microsoft.com/fwlink/?linkid=203888\&clcid=0x411) (英語) を参照してください。

64 ビット版の Outlook 2013 をインストールする場合、Outlook 用の 32 ビット版の MAPI アプリケーション、アドイン、およびマクロを 64 ビット版に更新する必要があります。詳細については、「64 ビット版の Office 2010」、「Building MAPI Applications on 32-Bit and 64-Bit Platforms (英語)」(https://go.microsoft.com/fwlink/?linkid=203889\&clcid=0x411) (英語)、および「Developing Outlook 2010 Solutions for 32-Bit and 64-Bit Systems (英語)」(https://go.microsoft.com/fwlink/?linkid=208699\&clcid=0x411) (英語) を参照してください。

並行インストールまたは仮想化の使用

コードの修正または再作成を行うための現実的な方法がない場合は、別の方法により互換性の問題の解決方法を探ることができます。

  • ベンダーによるアドインの更新を待機していて、更新版の入手が展開予定日より遅れる可能性がある場合には、Office 2003 またはそれ以前のバージョンを Office 2010 と並行してインストールするという方法を選択できます (Office Excel 2003 など、ベンダーの更新版アドインの対象となる特定のアプリケーションのみをインストールする方法もあります)。

    注意

    64 ビット版の Office 2010 に移行する場合には、並行インストールの 2007 Office system (またはそれ以前のバージョン) を同時にインストールしておくことはできません。以前のバージョンはすべて 32 ビット版のみ提供されています。

  • Windows 7 を使用している場合は、並行インストールの Office 2003 (またはそれ以前のバージョン) を Windows XP 互換モードでインストールできます。また、以前のバージョンの Office を使用している場合は、仮想コンピューティング環境にインストールできます。

  • App-V (旧称 SoftGrid) を使用します。App-V の詳細については、「Microsoft Application Virtualization 4.6 (英語)」(https://go.microsoft.com/fwlink/?linkid=143973\&clcid=0x411) (英語) を参照してください。

  • Windows ターミナル サービスを使用し、次のどちらかを実行します。

    • Windows Server 2003 を使用している場合は、Windows ターミナル サービスを使用して、以前のバージョンの Office と共にこれらのソリューションをリモートで実行できるデスクトップ コンピューターを提供できます。

    • Windows Server 2008 を使用している場合は、RemoteApp をインストールできます。RemoteApp では、ユーザーのクライアント コンピューター上で、レガシ アプリケーションおよびレガシ バージョンの Office の操作感を実現できます。RemoteApp の詳細については、「Windows Server 2008 ターミナル サービス RemoteApp を展開する」(https://go.microsoft.com/fwlink/?linkid=178280\&clcid=0x411) を参照してください。

修復後のアドインとアプリケーションのパイロット

Office 2010 を展開する前の最後の大きな手順として、パイロットの実施があります。パイロットは、修復後の成果物を提供するための最終的な基盤となるものであり、プロジェクト チームは Office 2010 のパイロット全体に関与し、発生した問題の把握と修正の役割を担う必要があります。パイロットでは、制御された環境下において、Office 2010 と連係する修復後のアプリケーションとアドインの新機能を使用してユーザーが通常のビジネス タスクを行い、リリース管理チームがこれを監視します。これにより、修復が予期したとおりに動作することと、組織のビジネス上の要件が満たされていることを確認できます。

パイロットで問題が報告された場合は、反復型の手法により、見つかった問題の修復、新しいテスト ケースの設計、およびテストの実施を行ったうえで、更新後のアプリケーションを展開して再度パイロットに回し、追加レビューを行います。これらの方法がうまく動作するかどうか、ユーザーのフィードバック、および修復後のアドインまたはアプリケーションが提供する機能の妨げとなる問題がないかどうかについては、特に注意を払う必要があります。

アプリケーションの安定化とパイロットの方法の詳細については、TechNet 技術ライブラリの「Microsoft Operations Framework 4.0」の「Stabilize Service Management Function (英語)」(https://go.microsoft.com/fwlink/?linkid=115624\&clcid=0x411) (英語) を参照してください。