Microsoft Office ドキュメントの作成には、多くの要素が関与します。その中には、すべての Office アプリケーションに共有される共通の要素もあります。たとえば、ドキュメント プロパティ、スタイル シート、グラフ、ハイパーリンク、図表、画像などがこれに該当します。一方、各アプリケーションに固有の要素もあります。Excel のワークシート、PowerPoint のスライド、Word のヘッダーとフッターなどです。

ユーザーが Office 2003 または以前のバージョンの Microsoft Office でドキュメントを保存すると、単一のファイルがディスクに書き込まれます。このファイルは、簡単に開くことができます。このように見えることは、実務の中でドキュメントを保存し、管理し、共有する上で非常に重要です。2007 Microsoft Office システムのドキュメントは、個々のパーツを ZIP コンテナに入れてパッケージ化することにより、以前と変わらず単一のファイルとして扱えるようになっています。単一のパッケージ ファイルを使用して単一のドキュメントの実体を表すため、ユーザーは、Office (2007) のドキュメントを保存したり開いたりするときに、以前のバージョンの Office でしていたのと同じように操作できます。引き続き、単一のファイルだけを扱えばよいのです。

以前のバージョンの Office では、Office ドキュメントのコンテンツを操作する必要のある開発者は、バイナリ ファイルで定義された構造化ストレージに従ってデータを読み取ったり書き込んだりする方法を理解しなければなりませんでした。Office のバイナリ ファイル形式は主に Office アプリケーションからアクセスされるものとして設計されていたため、このプロセスは複雑で難しいものでした。この形式は、アプリケーションのメモリ内での構造を反映しており、低速ハードディスクを持つメモリの少ないコンピュータでも処理できました。さらに、Office アプリケーションを使用せずにプログラミングによって Office のバイナリ ファイルを変更することは、ファイルを破損する主な原因とされていました。このため、ファイルの変更を試みることさえ思いとどまる開発者もいました。

ZIP が Office XML 形式のためのパッケージ形式として採用されたのは、これが業界内で非常によく理解されている標準形式であるためです。現在、ZIP 形式を扱えるツールは多数あります。ZIP を使用することにより、将来の機能拡張を可能にする柔軟なモジュール式の構造が得られます。このため、業界標準の ZIP ファイルを扱う膨大なツールとテクノロジのどれを使用しても、2007 Microsoft Office システムのドキュメントのコンテンツのあらゆる部分にアクセスできます。いったんコンテナ ファイルを開いたら、ドキュメントを定義するパッケージ内に見つかるあらゆる文書パーツを操作できるのです。たとえば、Office XML 形式を使用した Word 2007 ドキュメントを開いて、その Word ドキュメントの本文を表す XML パーツを探し出し、XML を編集できる任意のテクノロジを使用してそのパーツに変更を加え、その XML パーツをコンテナ パッケージに戻せば、改訂された Office ドキュメントが得られます。

Office XML 形式のパッケージ内には、そのファイルの多数の論理パーツが個々のファイル (パーツ) として保存されています。このモジュール性は、このファイル形式の重要な特性の 1 つです。モジュール性により、特定のパーツを短時間で突き止め、そのパーツだけに直接作業することが可能になります。業務上の具体的なニーズを満たすために、文書パーツを編集したり、交換したり、削除することもできるのです。

サムネール、メタデータ、メディア、リレーションシップなどのパーツは、すべての Office アプリケーションで共有されます。また、ドキュメント プロパティなどの特定のパーツは、一貫してすべてのファイルに存在します。一方、それが表すアプリケーション ドキュメントの種類に固有のパーツも多数あります。たとえば、ワークシート パーツは Excel ドキュメントにしか含まれないし、スライド マスタ パーツは PowerPoint ドキュメントにしか含まれません。

Open Packaging Conventions で規定されているいくつかの例外を除いて、実際のファイル ディレクトリ構造は不定です。ファイルの有効性は、ファイル構造ではなくパッケージ内のファイルのリレーションシップによって決まります。ZIP コンテナに入っている Office (2007) XML 形式のファイルのパーツは、リレーションシップを正しく修正して文書パーツが設計どおりの相互関係を保てるようにしさえすれば、自由に編成し直したり、名前変更したりできます。リレーションシップが正しければ、ファイルはエラーなしに開けます。Office XML 形式のファイルの最初のファイル構造は、生成された既定の構造です。この既定の構造は、ユーザーが Office XML 形式のファイルの構成を簡単に指定できるようになっています。リレーションシップを最新の状態に維持しさえすれば、この既定のファイル構造は自由に変更できます。この詳細については、「チュートリアル: Word 2007 オープン XML ファイル形式」を参照してください。

パーツには、さまざまなコンテンツ タイプがあります。Microsoft Office のアプリケーション データを表すために使用されるパーツは、XML として保存されます。これらのパーツは、関連する Office 機能や Office オブジェクトを定義する XML 参照スキーマに従っています。たとえば、Excel 2007 ファイルでは、ワークシートを表すデータは Excel ワークシート用の Office スキーマに従った XML パーツに格納されます。さらに、ブック内に複数のワークシートがある場合、パッケージ ファイルには各ワークシートに対応する XML パーツが格納されます。既定の Office 文書パーツを表すすべてのスキーマが、完全に文書化され、無償ライセンスで Microsoft から提供される予定です。そうなれば、XML ベースの標準的な任意のテクノロジを使用し、Office スキーマに関する知識を適用して、2007 Microsoft Office システムのドキュメントを簡単に解析したり作成したりできるようになります。

パーツをネイティブ コンテンツ タイプで保存する方が多くの利点が得られるシナリオも多くあります。これらのパーツは、XML としては保存されません。たとえば、2007 リリースの Office ドキュメントのイメージは、バイナリ ファイル (.png, .jpg、およびその他のファイル タイプ) として保存されます。したがって、ZIP アプリケーションを使用してパッケージ コンテナを開いたら、すぐにイメージをそのネイティブ形式で表示したり、編集したり、入れ替えたりできます。この保存アプローチは、アクセスしやすいだけでなく、必要な内部処理やディスク空間も、イメージをエンコードされた XML として保存するよりも少なくなります。その他にバイナリ パーツとして保存される注目すべきパーツとしては、VBA プロジェクトと埋め込み OLE オブジェクトがあります (埋め込み OLE オブジェクトがバイナリになるのは、関連付けられている OLE サーバーがバイナリでの表現しか提供していない場合だけです。たとえば、2007 Microsoft Office システムの埋め込み文書は、そのコンテンツを他のパッケージとして埋め込みます)。開発者にとっては、アクセスしやすさによって多くのシナリオがより魅力的になります。たとえば、2007 Microsoft Office システムのドキュメントのコレクションに反復処理を実行して、既存の OLE オブジェクトを新しいバージョンに更新するようなソリューションを構築できます。このようなソリューションやその他の膨大なシナリオが、Office アプリケーションを使用したり、そのドキュメント固有の XML に変更を加えたりすることなく実現できるのです。次のセクションでは、Office XML 形式をサポートするすべての Office 製品に共通のパーツをいくつか取り上げ、それらについて簡単に説明します。パーツの種類と数は、その ZIP コンテナ ファイルを生成したアプリケーションにより異なります。たとえば、Word 2007 ではドキュメント関連のパーツが生成されますが、PowerPoint 2007 ではスライド プレゼンテーション関連のパーツが生成されます。

<Relationship Id="someID" Type="relationshipType" Target="targetPart"/> 

パーツは、2007 リリースの Office ドキュメントを構成する個々の要素です。リレーションシップは、一連のパーツがどのように相互に関連して実際のドキュメントを形成するかを指定するために使用される手段です。リレーションシップの定義には、XML を使用します。リレーションシップは、ソース パーツとターゲット リソースの間の関係を指定します。たとえば、スライドとそのスライドに表示されるイメージの間の関係をリレーションシップにより指定できます。リレーションシップは、ドキュメント コンテナ内の "リレーションシップ パーツ" と呼ばれる XML パーツ内に格納されます。ソース パーツに複数のリレーションシップがある場合、2 つ目以降のリレーションシップもすべて同じ XML リレーションシップ パーツに記述されます。

リレーションシップは、Office XML 形式の中で重要な役割を果たします。すべての文書パーツが、少なくとも 1 つのリレーションシップから参照されます。リレーションシップを使用すれば、パーツのコンテンツを見なくても、パーツ間の相互関係を知ることができます。パーツ内では、リレーションシップへの参照がすべてリレーションシップ ID を使用して表されます。これにより、パーツ間の関係はすべて、コンテンツ固有のスキーマからは独立して維持することが可能になります。

例として、2 つのワークシートを持つ Excel 2007 ブックのリレーションシップ パーツを次に示します。

<Relationships xmlns="http://schemas.microsoft.com/package/2005/06/relationships"> 
<Relationship ID="rId3" 
   Type="http://schemas.microsoft.com/office/2005/8/relationships/xlStyles"
      Target="styles.xml"/> 
   <Relationship ID="rId2" 
Type="http://schemas.microsoft.com/office/2005/8/relationships/xlWorksheet" 
         Target="worksheets/Sheet2.xml"/> 
   <Relationship ID="rId1" 
      Type="http://schemas.microsoft.com/office/2005/8/relationships/xlWorksheet" 
         Target="worksheets/Sheet1.xml"/> 
   <Relationship ID="rId5" 
Type="http://schemas.microsoft.com/office/2005/8/relationships/xlMetadata" 
         Target="metadata.xml"/> 
   <Relationship ID="rId4" 
Type="http://schemas.microsoft.com/office/2005/8/relationships/xlSharedStrings" 
         Target="strings.xml"/> 
</Relationships>

リレーションシップは、ドキュメント内部での参照のみでなく、外部リソースも表します。たとえば、ドキュメントにリンクされた図やオブジェクトがある場合、これらもリレーションシップを使用して表されます。これにより、ドキュメント内にある外部ソースへのリンクの確認、検証、および変更が簡単になります。また、リンク切れした外部リンクの修復や、見慣れないソースの検証、有害である可能性のあるリンクの削除もやりやすくなります。

開発者には、Office XML 形式のリレーションシップを使用するとさまざまな形で利点が得られます。パーツを見つけるためにドキュメント固有の XML を解析する必要もなければ、ドキュメントの内部リソースや外部リソースを見つけるためにドキュメント固有の XML を解析する必要もないため、リレーションシップにより、ドキュメント内のコンテンツが置かれている場所を突き止めるプロセスが簡単になります。リレーションシップにより、ドキュメント内のすべてのコンテンツの一覧が簡単に入手できるようになるのです。たとえば、Excel ブック内のワークシートの数を知りたい場合、リレーションシップにあるシート パーツの数を調べるだけで済みます。また、ドキュメントのコンテンツの種類を調べるのにもリレーションシップを使用できます。これは、ドキュメント内に有害である可能性のある特定の種類のコンテンツ (疑わしい OLE オブジェクトなど) が含まれていないどうかかを調べる必要がある場合や、役立つコンテンツを探している場合 (別の場所での再利用のためにドキュメントからすべての JPEG イメージを抽出したい場合など) に便利です。

リレーションシップは、アプリケーション固有の構文やコンテンツ マークアップを学習せずにドキュメントを操作することも可能にします。たとえば、開発者は PowerPoint のプログラミング方法などを一切知らなくても、ドキュメントのリレーションシップを編集するだけで、プレゼンテーションから無関係なスライドを簡単に削除することができます。

Office XML 形式で保存された 2007 Microsoft Office システム ドキュメントは、既定ではマクロなしのファイルになるものと想定されており、コードを含むことができません。このため、既定のドキュメント内に存在する悪意のあるコードが予想外に実行されることは決してありません。2007 Microsoft Office システムのドキュメントにもマクロを挿入して使用することは可能ですが、そうするには、ユーザーまたは開発者がそのドキュメントをマクロ有効文書という種類で保存する必要があります。この安全措置によって、開発者のソリューション構築には影響を与えることなく、組織が安心してドキュメントを使用できるようになります。

マクロ有効ファイルは、マクロなしのファイルとまったく同じファイル形式を持ちますが、それに加えてマクロなしのファイルにはない追加のパーツも含みます。追加パーツは、ドキュメントに入れられた自動化の種類によって異なります。VBA を使用するマクロ有効ファイルには、VBA プロジェクトを格納するバイナリ パーツが含まれます。Excel 4.0 スタイルのマクロ (XLM マクロ) を使用している Excel ブックや、コマンド ボタンを含む PowerPoint プレゼンテーションも、すべてマクロ有効ファイルとして保存されます。マクロなしファイル内にコード固有のパーツが見つかった場合、それが誤って配置されたのか悪意を持って配置されたのかに関係なく、Office アプリケーションは決してコードの実行を許可しません。これに例外はありません。

Microsoft Office 2007 システムのドキュメントは、ドキュメントを開く前にドキュメント内にコードが存在するかどうかを調べることができます。以前は、この "事前の確認" を Office 外で行うことは簡単には実現できませんでした。パッケージ ファイルを検査すれば、Office を実行しなくても、コードベースのパーツまたはリレーションシップが存在するかどうかを調べることができます。危険なコードを実行してしまう可能性もありません。ファイルが疑わしい場合は、コードを実行する可能性のあるパーツはすべてファイルから削除して、コードによる害の発生を確実に防ぐことができます。

Office XML 形式を使用して保存した 2007 Microsoft Office システム ドキュメントには、以前のバージョンの Office で使用されていたバイナリ ドキュメントと区別がつくように、新しいファイル名拡張子が与えられます。新しい拡張子は、以前のバイナリ ファイルのファイル名拡張子を流用し、その末尾に 1 文字追加したものになっています。Word 2007、Excel 2007、PowerPoint 2007 で新しいファイル形式を使用して作成したドキュメントの既定の拡張子は、"x" という文字が最後に追加されて、それぞれ .docx, .xlsx, .pptx になります。新しいファイル形式を使用したその他の種類の Office ドキュメント (テンプレート、アドイン、PowerPoint ショーなど) にも新しい拡張子が付けられます。

2007 Office リリースで導入されたその他の新しい変更点として、マクロ有効ファイルにはマクロのないファイルとは異なる拡張子が与えられることが挙げられます。マクロ有効ドキュメントのファイル名拡張子は、"x" ではなく "m" で終わります。たとえば、Word 2007 のマクロ有効ドキュメントの拡張子は .docm になります。これにより、どのユーザーもソフトウェア アプリケーションも、ドキュメントを開く前にそのドキュメントにコードが含まれていることを認識できます。

データ交換手段の一般的な標準として XML が出現した今、新しい Office XML 形式を導入することは、ドキュメント ベースのデータにさまざまな異種システムからアクセスしやすくなるということを意味します。XML が Microsoft Office ドキュメントの既定のファイル形式になったということは、ドキュメント データを部署内全体で共有しているのか、それとも 2 つの組織間でビジネス データを交換しているのかなどに関係なく、Office アプリケーションが、以前のバイナリ形式で強いられていたような制限なしにビジネス プロセスに参加できるようになるということを意味するのです。

新しいファイル形式のオープン性は、データのロックを解除し、デスクトップを超えた幅広い、新しいレベルの統合を持ち込みます。たとえば、新しいファイル形式の公開された仕様を参照すれば、Office アプリケーションを使用しなくても、豊富なデータを持つドキュメントを作成できます。サーバー側のアプリケーションでは、ドキュメントをまとめて処理して、企業データを従業員が使い慣れた柔軟な Office アプリケーションで操作できる形にすることができます。また、XPath (一般的な XML クエリ言語) や拡張スタイルシート言語変換 (XSLT) などの標準の XML プロトコルを使用して、データをドキュメントから取り出したり、ドキュメント内のコンテンツを外部データから更新したりすることもできます。

このようなシナリオの 1 つとして、何千というドキュメントをパーソナライズして顧客に配信するシナリオが考えられます。エンタープライズ データベースまたはカスタマ リレーションシップ マネジメント (CRM) アプリケーションから取り出した XML を使用するサーバー アプリケーションを使用することにより、標準のドキュメント テンプレートにプログラミングで情報を挿入するのです。Office アプリケーションを実行する必要がなく、それでも高品質の豊かな Office ドキュメントを再生することができるため、このようなドキュメントの作成は非常に効率的です。

Office でのカスタム スキーマの使用は、ドキュメントをデータの共有に使用するためのもう 1 つの方法です。かつてはバイナリ形式に縛られていた情報に簡単にアクセスできるようになったため、ドキュメントをオープンに交換できるデータ ソースとして提供できるようになったのです。カスタム スキーマは、データの挿入や抽出を簡単にするだけでなく、ドキュメントに構造も追加し、データの有効性を検証することもできます。

Office XML 形式によってプロセスを向上させることができるもう 1 つの貴重な例として、既存の Office ドキュメントのコンテンツ編集が挙げられます。編集には、少量のデータの更新、パーツ全体の入れ替え、パーツの削除、新しいパーツの全体的な追加などがあります。新しいファイル形式では、リレーションシップとパーツを使用することにより、コンテンツが見つけやすく、操作しやすくなります。XML と XML スキーマを使用すれば、XPath、XSLT などの一般的な XML テクノロジを使用して、事実上無制限の方法でドキュメント パーツ内のデータを編集できるのです。

Word ドキュメントのヘッダー内のテキストを編集する必要があるというシナリオも考えられます。もちろん、1 つのドキュメントに行う作業を自動化するというのは実際的ではありません。しかし、たとえば会社が合併し、何百という文書のヘッダーに入っている会社名を新しい社名に更新する必要が生じたとしたらどうでしょう。このような場合は、すべてのドキュメントをループ処理し、Word ファイルの構造内のヘッダー パーツを探し出し、古いテキストを検索する XPath クエリを実行するコードを開発者が記述すればよいのです。このコードでは、さらに新しいテキストを挿入し、ヘッダー パーツを置き換え、すべてのドキュメントを更新し終えるまでこの処理を繰り返します。自動化により、膨大な時間を節約することができ、コードを使わなければできなかったようなプロセスが可能になり、手作業のプロセスで発生する可能性のある間違いも防ぐことができます。

その他には、全体に使用される 1 つのパーツだけを変更することにより、既存の Office ドキュメントを更新しなければならないようなシナリオが考えられます。Excel 2007 のブックでは、パーツを上書きすることにより、古いデータまたは使われなくなった計算モデルの入っているワークシート全体を新しいワークシートに置き換えることができます。このような更新は、バイナリ パーツにも適用されます。必要に応じて、既存のイメージや、OLE オブジェクトでさえも、新しいものと入れ替えることが可能です。OLE オブジェクトとして Office ドキュメントに埋め込まれた Microsoft Office Visio の図面を、そのバイナリ パーツを上書きすることにより更新したりできるのです。ハイパーリンクに入っている URL を新しい場所を指すように更新することもできます。

以下、各アプリケーション固有のシナリオを紹介します。

Word ドキュメントに "定型文" を入れるのは、ビジネスの現場でよくあることです。たとえば、会社で作成した公式ドキュメントには、必ず正式な免責事項や契約条件の開示を入れなければならない会社もあります。その他に考えられる定型文の一般的な例は、営業の提案作成や会社から正式に発行するお知らせに使用する "会社概要" です。Word には書式設定されたテキストを挿入できる定型句などの機能が備わっていますが、この機能は、Word による自動化かユーザーの直接操作が必要であるため適用できる規模が限られています。

Word 2007 には、ドキュメントにコンテンツを挿入するための非常に柔軟性に優れた別の方法があります。Word XML 形式では、Word を開いたときにドキュメント全体から参照される文書パーツを追加することができます。つまり、文書パーツのライブラリを構築できるのです。文書パーツは、Word で表示できるドキュメント形式から取り出すことができ、Word ドキュメント ソリューションの中で必要に応じてプログラミングにより再利用できます。

Word コンテンツを操作するためのこの幅広い機能により、サーバー側でのドキュメントの組み立てなどの興味深いシナリオが実現します。前述の例に話を戻すと、サーバー上で作成されたドキュメントに自動的に免責事項を挿入することができます。社内で作成されたすべてのドキュメントに現地の言語での免責事項を入れることになっている多国籍企業について考えてみてください。このような会社では、適切な言語での免責事項を .html ファイルとして作成し、それをサーバーに保存しておきます。そして、ドキュメントを構築するアプリケーションで、必要な言語に対応するドキュメント部分をパーツとしてドキュメント コンテナに挿入すればよいのです。こうして挿入した部分は、Word ドキュメントの一部としてシームレスに表示されます。

負荷を最適化し、パフォーマンスを向上させて、ファイル サイズを小さくするために、Excel 2007 では、Excel ファイル内に繰り返し出現するテキストは 1 つのコピーしか保存されないようになっています。これを行うために、Excel では、http://schemas.microsoft.com/office/2005/8/relationships/xlSharedStrings リレーションシップのターゲットで指定される文書パーツ内に共有文字列テーブルが格納されます。このパーツには、ブック内で見つかった一意のテキスト値がそれぞれ 1 度ずつ追加されます。個々のワークシート セルは、この文字列テーブルを参照してその値を取得します。

このプロセスは、Excel XML 形式を最適化すると同時に、その他のコンテンツ操作ソリューションに利用できる興味深い可能性も与えてくれます。多国籍企業の開発者は、共有文字列テーブルを使用して多言語サポートを提供することができます。サポートする必要のある各言語に 1 つずつブックを作成しなくても、単一のブックで必要な言語に対応する文字列テーブルを使用すればよいのです。その他には、文字列テーブルを使用して、一連のブック内にあるキーワードを検索することもできます。文字列が入った単一のテキストのみの XML ドキュメントの処理は、多数のワークシートや多数のブックに渡って Excel のオブジェクト モデルを操作するより高速かつ簡単になります。

PowerPoint 2007 のプレゼンテーションを PowerPoint XML 形式で保存すると、コンテンツが非常にアクセスしやすい状態になります。PowerPoint では、今回の PowerPoint が XML 形式を提供する初めてのバージョンとなるので、これにより以前のバージョンでは不可能だった数多くのシナリオへの可能性が開かれます。テキスト形式のスライドとスライド メモに完全にアクセスできるようになったのです。検索やインデックス処理、プレゼンテーション コンテンツの作成を必要とするソリューションが実現可能になりました。XML を使用して、簡単にデータ駆動型のプレゼンテーションを作成できます。そして、スライド マスタやスライド レイアウトにも XML パーツを通じてアクセスすることができ、既存の PowerPoint プレゼンテーションや新しい PowerPoint プレゼンテーションの書式をプログラミングで設定できます。

既存のプレゼンテーションからは独立して保存されているスライドのカタログを使用するアプリケーションを作成することにより、PowerPoint プレゼンテーションのコンテンツを組み立てたり再利用したりするのに別のアプローチを取ることができます。スライドは個別の XML パーツとして表されるため、社内の PowerPoint 2007 スライドをデータとして保存し、管理する方法を最適化したソリューションが可能です。ユーザーが PowerPoint 外からスライドを探して選択することによりプレゼンテーションを作成できる "スライド ビューア" を記述することもできます。さらに、アプリケーションを Web ベースにして、一元管理を実現することも可能です。

Office XML 形式のモジュール性は、いったんコンテンツを生成した後、それを他のいくつものドキュメントの中で別の用途に利用するという可能性を開きます。開発者の方なら、いくつもの基本テンプレートを作成し、各部を他のドキュメントの構築ブロックとして再利用するようすが想像できることでしょう。たとえば、ある Word ドキュメントで作成した表を他の Word ドキュメントで使用したりできるのです。いったん作成したグラフは、さまざまな種類のドキュメント内で何度でも再利用できます (グラフは、すべての 2007 Microsoft Office システム アプリケーション間で共通のスキーマを持ちます)。この形式へのアクセスのしやすさゆえ、コンテンツ共有のあらゆる可能性につながります。

考えられるシナリオの 1 つとして、ドキュメントで使用するイメージのリポジトリを作成する必要がある場合が考えられます。これには、一連の Office ドキュメントからイメージを抽出し、ユーザーがそれを単一のアクセス先から再利用できるようにするソリューションを作成できます。2007 リリースの Office ドキュメントでは、イメージが一切変更されないままバイナリ パーツとして保存されるので、このようなソリューションを作成し、イメージのライブラリを簡単に維持することができるのです。以前に使用されたことのあるイメージを組み込みたいユーザーは、イメージを探すときに、一連のドキュメントを 1 つずついちいち開いてから閉じて調べていく必要はありません。カスタム アプリケーションを使用してリポジトリ内でイメージを探し、見つかったイメージをすぐに作業中のドキュメントに挿入できるのです。

よく似たアプリケーションとして、ドキュメントから抽出したドキュメントの "サムネール" イメージを再利用し、ドキュメントの管理プロセスに視覚的な情報を追加するアプリケーションを作成することもできます。

開発者からの最も一般的な要求の 1 つに、サーバー上で Microsoft Office アプリケーションを自動化することなく Microsoft Office ドキュメントを作成できるようにするというものがあります。豊富なデータを含む複雑なドキュメントを作成する必要がある企業や、大量のドキュメントを組み立てる必要のある企業は、高度な目的のための処理を効率化することを望んでいます。技術的には、Office アプリケーションはサーバーから実行するようには記述されていないし、サーバーからの実行をサポートしてもいません。

Microsoft Office 2003 Editions では、Office 2003 XML 参照スキーマに従って生成された XML ドキュメント形式の導入が、この制限の克服に役立っていました。Office スキーマに従っている限り、XML を組み立てることができる任意のテクノロジで Word または Excel のドキュメントを作成できたのです。その時点ではこれは非常に大きな進歩でしたが、残念ながら Excel と Word にしか適用されなかったうえ、XML ファイルで完全に忠実なドキュメントがサポートされたのは Word だけでした。2007 Office リリースでは、これを基盤として、PowerPoint XML ファイルが追加され、PowerPoint XML ファイルと Excel XML ファイルも完全に忠実なドキュメントをサポートするようになりました。

このテクノロジの進歩により、2007 Office リリースでは、Office を一切開かずに Excel、Word、および PowerPoint のドキュメントを生成する Office ソリューションを作成できるようになりました。このソリューションでは、2007 リリースのスキーマに従って XML を作成し、Office XML 形式で定義されているようにパッケージ コンテンツを作成する必要があります。Microsoft Office アプリケーションが提供する豊富な一連の機能を完全に表すために、Office スキーマは非常に広範になっていますが、1 つのドキュメントを生成するためにこの形式で定義されているすべての構造が必要になるわけではありません。各 Office アプリケーションが定義済みの最小限の項目を持つファイルを開くことができ、したがって、多数のドキュメントを作成することも簡単です。

ドキュメントの組み立ては、新しいドキュメントに関してのみ行われるわけではありません。もちろん、Office XML 形式のルールに従うことにより、Office を使用しなくてもプログラミングでドキュメントを作成できます。しかし、多くの場合、ドキュメントの組み立てとは、既存のドキュメントやデータ、その他のコンテンツの一部分を使用してのドキュメント作成を意味します。新しい Office XML 形式は、モジュール式のアーキテクチャを持っており、そのコンテンツが XML ベースであるため、このようなシナリオにうまく適合します。

ドキュメントの組み立ての例は、PowerPoint プレゼンテーションにも適用されます。多くの企業が、再利用の価値のある膨大な PowerPoint ファイルを保有しています。ユーザーは、しばしば、以前からある複数のプレゼンテーションからスライドを流用して別のプレゼンテーションや関連プレゼンテーションを作成します。スライドの検索、調整、および統合 (コピーと貼り付け) は、一般に、時間がかかるうえ繰り返しの多い作業で、多くの企業が顧客向けのプレゼンテーションについてこの作業の自動化を望んでいます。2007 Office リリースでは、PowerPoint プレゼンテーション ファイル内の個々のスライドが、プレゼンテーション コンテナ パッケージに入れられたスライド用の XML パーツ内で完結した形で存在するため、個別にアクセスできる状態になっています。カスタム ソリューションでは、このアーキテクチャを使用して、プレゼンテーションの組み立てプロセスを完全に自動化することができます。個々のスライドに関するメタデータの格納にカスタム XML を使用すれば、ユーザーは、定義済みのキーワードを使用して簡単にスライドを検索できるようになります。ユーザーがスライドを選択した後は、そのソリューションで、組み立てているプレゼンテーションにスライドの XML パーツを挿入し、参照リレーションシップを作成します。

セキュリティは、今日の情報テクノロジでは非常に重要です。Office XML 形式により、Office ドキュメントでの作業やドキュメントのセキュリティを考慮したソリューションの提供を以前より安心して行えるようになります。新しいファイル形式では、認識されている潜在的なあらゆる脆弱性を、それらが問題を発生させる前に検索して削除するソリューションを構築できます。

たとえば、アーカイブ ライブラリに保存するためのドキュメントを準備するソリューションが必要な場合、そこでカスタム コードを実行する必要が生じることは決してないし、顧客に送信するにはマクロのないドキュメントを用意するソリューションが必要になります。一連のドキュメントに反復処理を実行し、http://schemas.microsoft.com/office/2006/relationships/vbaProject リレーションシップのターゲットで指定されているパーツを削除することにより、Office ドキュメントの本文からすべての VBA コードを削除するアプリケーションを記述できます。これにより、より品質の高い一連のドキュメントが得られます。

さらに、Office XML 形式では、マクロ コードを実行できるファイルの種類が 2007 リリースの各製品に対して 1 つずつ提供されます (.docm は Word 用, .xlsm は Excel 用, .pptm は PowerPoint 用)。拡張子の末尾が "m" で終わらないファイルの種類では、たとえマクロ コードが含まれていたとしても、そのコードは決して実行されません。このため、これらのファイルの種類で作業していれば、ユーザーは悪意のあるソフトウェアから確実に保護されます。

残念ながら、Office ユーザーにとっての潜在的なセキュリティ脅威はマクロ コードだけではありません。最近では、バイナリの .jpg ファイルにセキュリティ上の脆弱性が見つかりました。OLE オブジェクトやイメージなどのバイナリ ファイルからの潜在的なリスクは、Office ドキュメントを調べて、検出された脆弱性をすべて削除することにより回避できます。たとえば、特定の OLE オブジェクトが既知のセキュリティ脅威として認識された場合は、そのオブジェクトを含むすべてのドキュメントを探し出して駆除または検疫するようなアプリケーションを作成できます。同様に、リレーションシップ パーツを調べることにより、2007 Microsoft Office システムのドキュメントから参照される外部参照も簡単に識別できます。ソリューション開発者は、この識別によって、ドキュメントから参照されている外部リソースが信頼できるものなのか、それとも修正措置が必要なのかを判断することができます。

パーツは、コンテンツ タイプとリレーションシップによりブロックできます。たとえば、IT 管理者は, .gif イメージにセキュリティ脅威が含まれている可能性があることに気づいた場合、グループ ポリシーの設定を使用して image/gif コンテンツの 2007 Microsoft Office システム ドキュメントへの読み込みを禁止することができます。適正なセキュリティ パッチを適用した後は、この設定を無効にできます。IT 管理者は、こうして確実かつ迅速にユーザーを保護することができます。

パーツのブロックは、形式ポリシーを通じて行うこともできます。たとえば、IT 管理者が、正しくない形式のコメントにより PowerPoint にバッファ オーバーフローのエラーが発生するという脆弱性を見つけた場合、Office ファイルの形式ポリシーの導入によってユーザーとそのコンピュータを保護できます。この場合、コンテンツ タイプ (この例の場合はテキストの入っている XML) でブロックするよりも、schemas.microsoft.com/office/2006/relationships/comments リレーションシップ タイプをブロックすることによってコメントのみを特異的にブロックする方が適切です。これを行うには、管理者が Microsoft Office ポリシー テンプレート (.adm ファイル) を使用して該当オプションを設定します。Office ポリシー テンプレートの使用方法の詳細については、マイクロソフト サポート技術情報の記事「管理者が Office ポリシー テンプレートを Windows のグループ ポリシー設定で使用する方法」を参照してください。

悪意のあるコンテンツからユーザーを保護することを模索する中で、ユーザーが誤って不適切にデータを共有するのを防ぐこともできます。共有が不適切なデータとは、ドキュメントに個人識別情報 (PII) の形で保存されているデータのこともあれば、部外秘または社外秘として指定された変更履歴やコメント、注釈のこともあります。どちらのタイプの情報も、ドキュメント全体を隅々まで調べることなく、プログラミングによって直接削除することができます。たとえば、ドキュメントのコメントを削除するには、コメント パーツのリレーションシップがないかどうかを調べ、見つかった場合は、関連付けられているコメント パーツを削除します。

Office XML 形式では、PII とコメントのセキュリティを確保できるだけでなく、これらの情報にアクセスすることもでき、それが他の方法で役立つ場合もあります。たとえば、PII データを使用して、特定の個人により作成されたか、または特定の企業からのドキュメントの一覧を取得するようなソリューションを作成できます。新しいファイル形式では、Office を開いたり、そのオブジェクト モデルを使用したりしなくても、この一覧を生成することができるのです。同様に、Office ドキュメントの入っているフォルダ内またはボリューム内をループ処理して、一連のドキュメント内のコメントをすべて集約するようなアプリケーションも作成できます。また、その他の条件を適用してコメントを限定したり、ユーザーがドキュメントを作成する際にグループ作業をより管理しやすくしたりできます。

Office XML 形式を使用した Office ドキュメントのその他の多数の面と同様に、ドキュメントのスタイル、書式、およびフォントも、コンテナ パッケージ内の独立した XML パーツに入れて管理されます。このため、ここでもやはり、この分離による利点を生かしたソリューションを作成できます。企業によっては、非常に特異なドキュメント標準を持っており、これらの管理に非常に時間がかかる場合があります。しかし、たとえば、ドキュメント内のフォントの変更や置き換えなどは、Office を開かなくても行えます。

また、内容は同じものの、部署ごと、場所ごと、子会社ごと、またはターゲットとなる顧客ごとに異なる書式を持つコンテンツのドキュメントがあるというのもよくあることです。このようなコンテンツは単一のドキュメントに入れて保守し、必要に応じて新しいスタイルを適用できます。これを行うには、http://schemas.microsoft.com/office/2006/relationships/styleSheet リレーションシップのターゲットで指定されているパーツを別のパーツに入れ替えます。この入れ替えできるという機能により、膨大なドキュメント内のコンテンツを管理する必要がなくなり、ドキュメントの表示を制御するプロセスが簡単になります。

効率的なドキュメントの管理は、情報テクノロジの世界で長年に渡る課題でした。Microsoft Office 2003 では、作成者、タイトル、サブタイトルなどの以前からある Office ドキュメント プロパティに OLE を使用してアクセスできます。新しい Office XML 形式では、ドキュメント プロパティがドキュメント内の独立したパーツになったため、ドキュメント プロパティにも簡単にアクセスできます。次に示すのは、Word .docx ファイルでのドキュメント プロパティ パーツの一例です。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<CoreProperties xmlns="http://schemas.microsoft.com/package/2005/06/md/core-properties"> 
   <Title>Word Document Sample</Title> 
   <Subject>Microsoft Office Word 2007</Subject> 
   <Creator>2007 Microsoft Office System User</Creator> 
   <Keywords/> 
   <Description>2007 Microsoft Office system .docx file</Description> 
   <LastModifiedBy>2007 Microsoft Office System User</LastModifiedBy> 
   <Revision>2</Revision> 
   <DateCreated>2005-05-05T20:01:00Z</DateCreated> 
   <DateModified>2005-05-05T20:02:00Z</DateModified> 
</CoreProperties> 

新しいファイル形式を使用した Office ドキュメントでは、Office ベースのプロパティで提供される内容を超えてさらに独自のデータやコンテンツを追加することができ、高度なドキュメント プロパティ管理に活用できます。独自にカスタム定義の XML を作成し、それを別のパーツとしてファイルに入れるのです。この XML は、Office XML 形式にアクセスできる任意のツールまたはアプリケーションで使用できます。