「Officeアドイン」の作り方と、できること／できないこと：特集：Officeストアで世界に飛び出そう！ 最新Office 2013アプリ開発入門（後編）（2/4 ページ）

作り方次第で、さまざまな応用 ―― メール・アドイン

　一方、メール・アドイン（Mail Add-ins）では、かなり事情が異なっている。まず、典型的なメール・アドインの処理は、前編で紹介した動作から分かるように、メール・メッセージや予定などから必要なデータを読み込み、そのデータに関する情報を扱うようなアプリだ（詳しくは前編の「Bing Map」のメール・アドインを参照してほしい）。

　例えば下記のHTMLコードは、参照しているメール・メッセージの本文にGoogleマップのURLを含んでいる場合に、その地図を（iframeで）表示するメール・アドインだ。なお、下記の「Rule」の記述方法については、前編を参照していただきたい。

　上記のコードのメール・アドインを実際に実行すると、次の画面のようになる。

実行結果

　こうした典型的なメール・アドインは、メール・メッセージの送信や予定作成（あるいは会議作成）などの操作画面ではなく、上の実行結果のように情報の確認画面で使用されるため、どうしても「読み込み」を主体とした処理になるだろう。また、作業ウィンドウ・アドイン、コンテンツ・アドインと同様に、リボンのカスタマイズなど、既存コントロールのカスタマイズは不可能だ。

　さて、ここまで読むと、メール・アドインもあまり応用的な処理はできないように思ってしまうかもしれないが、実は、プログラミング方法次第で、かなり広範囲な処理が可能になっている。

　作業ウィンドウ・アドイン、コンテンツ・アドインが、Excel、Word、PowerPointなどに共通の基本的なオブジェクト（＝コンテンツやファイルなど）のみを扱うのに対し、メール・アドインではOutlookやExchange Serverに固有の多くのオブジェクトを対象としている。例えば、カスタム・プロパティ（＝メール・メッセージのタイトル、本文、送信者などの既存のプロパティではなく、ユーザーやプログラマーが独自に定義した内部プロパティ）やユーザー・プロファイルを組み合わせた処理なども可能だ。

　さらに例えば、現在開いているメール・メッセージ以外のほかのメール・メッセージにアクセスする場合や、現在開いているメール・メッセージに関連して別のメール・メッセージの送信や予定作成を行う場合など、提供されているオブジェクト・モデル（JavaScript API）の範囲を超えた処理が必要な場合、「Exchange Webサービス（EWS）」と呼ばれるHTTPによるWebのAPIをメール・アドインから呼び出して処理することが可能だ（その場合、JavaScriptのmakeEwsRequestAsync関数を使用する）。

　特に近年、マイクロソフトにおけるメール関連のプログラミングでは、インターネット環境でも使用できるExchange Webサービスに多くの機能が追加されており、最新のOutlookで実現できることの多くが、このExchange Webサービスでも同様に使用できるようになっている（例えば、メール・ヒントなども、そうした機能の1つだ）。メール・アドインで、このExchange Webサービスが扱えることで、Outlook同等の広範囲な処理を追加できるわけだ。

　なお、このAPI（makeEwsRequestAsync関数）は賢く、Exchange Webサービスの呼び出しにおけるクロス・ドメインの問題も内部で解決してくれている（内部では、Outlook 2013クライアントやOutlook Web Appなど、状況に応じて呼び出し方を変えることで、クロス・ドメインの問題を回避している。プログラマーは、一切こうした心配をする必要はない）。

　ただしメール・アドインでは、こうした柔軟性のトレード・オフとして考慮すべき点も多くあるので注意してほしい。例えばExchange Webサービスは、SOAP（Simple Object Access Protocol）によるWeb APIであるため、JSONフォーマットのデータ交換と異なり、面倒なXMLを扱ったデータ処理が必要になる（jQueryを使ってXMLデータをパースするなどの工夫が必要だ）。なお、このような場合には、getCallbackTokenAsyncメソッドを使用してOAuthのaccess tokenを取得できるので、これを使ってOutlook REST API（Office 365 API）を呼び出すことができる。

　加えて、Exchange Webサービスの呼び出しのように、読み込み以外の高い権限の操作を必要とするメール・アドインは、インストールの際に、Exchange Serverの管理者権限が必要となるので注意してほしい。つまりExchange Webサービスを使った処理は、柔軟性はあるものの、お世辞にも気軽に使えるライトな手法とは言いにくい。

　また、こうした細かな処理を行うメール・アドインでは、ユーザーがログインしているアカウントも強く意識した実装（例えばユーザーごとに独自の情報をメール・ボックスに保持するなど）が必要となってくるだろう。前編ではOfficeアドインが持つシンプルな思想を強調したが、こうした高度なメール・アドインでは、OutlookやExchange Serverが持つ独自な性質に引きずられる点も多いので注意が必要だ。

Officeアドインのコンテキストとドキュメント連携

　Officeアドインでは、そのアプリが有効なコンテキスト（すなわち、どの範囲でその機能が使用可能か）にも注意してほしい。

　まず作業ウィンドウ・アドインとコンテンツ・アドインは、まるでシート上に貼られた画像データのように、Officeのコンテンツ（すなわち、ExcelブックやWord文書など）に付帯している。例えば、あるOfficeアドインを挿入したExcelブックを、そのアプリを使っていない別のユーザーのExcel 2013で開いても、このアプリは正常に表示される。

　従来のアドインのように、Officeそのもの（Excel、Wordなどのクライアントそのもの）に付帯された機能ではない（ただし、添付されたOfficeアドインを使用するには、Officeストアのアプリか、あるいは、前編で紹介した［信頼できるアプリ・カタログ］に登録されているアプリである必要がある）。

　また、こうした仕様から、作業ウィンドウ・アドインやコンテンツ・アドインは、例えば財務諸表の計算シートなどの、（ExcelブックやWord文書の）テンプレートと共に提供することもできる。特にWordアプリでは、Word文書の入力領域（コンテンツ・コントロール）と連携したOfficeアドインも作れるので、高度な入力補助を持ったWordのフォームなどもOfficeアドインと共に提供できる（実際に提供するには、WordアプリでCustom XMLを使用する。本稿では、そのプログラミング方法の説明は割愛する。次の画面はその例だ）。

コンテンツ・コントロールとCustom XMLを使ったWordアプリの例（顧客情報を検索して、Word文書内に挿入するアプリ）

　一方、メール・アドインは、こうしたコンテンツ（すなわち、個別のメール・メッセージや個別の予定など）に付与されるものではない。例えば、あるメール・メッセージをユーザーAとユーザーBが受信した場合、このメール・メッセージで使用可能なアプリは、双方のユーザーにより異なる。つまり、メール・アドインは、使用しているユーザー（メール・ボックス）やサーバの単位で機能が付与される。