はじめに
「Officeアドイン」は、ざっくり言うとOffice上で動作するWebアプリケーションです。
Office2013から登場し、Office2016、Office365(クライアント版)、Office365(Web版)など、様々なOfficeで動作します。
Officeアドインは2013年頃に登場し、細々と機能追加を繰り返してきました。
しかし、いかんせんノウハウと情報が少ないです。
そしてこの技術を使えるエンジニアの方も非常に少ないので、なかなか広まらないのも事実です。
「Officeアドイン」と日本語で検索すると、MS公式か、ほとんどが自分の発信な気がしてます・・・笑
（先日、「officeアドイン」で検索したら、MS公式ページより先に、自分の過去の発信が上位に出てきました笑）
そしてもう一つ。
このOfficeアドインは、いかんせん情報が少ないこともあり、いざやってみると、意外なところで詰まってしまう「地雷」が多いです。
そこで今回は、幾多の案件を行ってきて、この地雷に立ち向かってきた自分が、「Officeアドインで気を付けなければいけないところ」についてまとめます。
今後、もしOfficeアドインを案件や自社開発などで使用することを検討している方は、まずこの記事を読んでいただいて、事前に検証いただけることをオススメします。
地雷まとめ
Officeの種類によって、出来ることがぜんぜん違う
OfficeアドインはOffice2013から登場した、ということは上記で説明しました。
そこからOffice2016、Office365(クライアント版)、Office365(Web版)と増えてくるにつれて、出来る機能も増えてきました。
ですが、その出来る機能が、すべてのOfficeで使えるものではありません。
例えば「アドインコマンド」。これはOfficeのメニューにコマンドを追加するという機能です。
あらかじめアドインを設定しておけば、以降わざわざOfficeアドインを選択しなくても、メニューボタンをクリックするだけでアドインを実行できます。
※引用：(https://docs.microsoft.com/ja-jp/office/dev/add-ins/design/add-in-commands)
しかし、この機能はOffice2013とOffice2016では動作しません（ただしOutlook2016のみOK）。
こちらにアドイン コマンドの要件セットというページがあるのですが、ここでアドインコマンドは、Office2013と2016は「N/A」や「16.0.4678.1000 Supported in Outlook only」となっています。
つまり非対応ですね。
最新のOfficeだけで合わせると、「これ出来なかったのか」という事故につながるので、気をつける必要があります。
なお、各Officeで出来ること、出来ないことは、以下のページをご参照ください。
Office Common API requirement sets
Officeのログイン者情報を、Officeアドインで取得することはできない
Office2013から、Officeにログインを行うことができます。
なのでOfficeアドインを始める際、「このログイン情報を取得しよう」と誰もが思うでしょう。このログイン情報からアクセストークンを取得し、ゴニョゴニョしよう、ということです。
ですが、このOfficeの情報を、Officeアドインでは取得することが、現在は出来ません。
なので、ユーザーのOffice365の情報を絡めたアプリを作成する場合、ユーザーは再度、サインインページを表示する必要があります。
なお正確に言うと、2019/04/13現在、上記機能はプレビュー版です。Identity APIという名前で、現在プレビュー版ということで実装しているようです。
ただし、それでもやはり「Office 2013 or later for Windows」では「N/A」になっているので、いずれにせよOffice2013と2016は切り捨てて実装しなければなりません。
認証が絡む場合、Office Onlineには本当に注意
クライアント版のOfficeアドインが、Office Onlineでも動作すると思っていると、確実に失敗します。
なぜなら、クライアント版のOfficeアドインと、Office OnlineのOfficeアドインは、作られ方がぜんぜん違うからです。
クライアント版のOfficeアドインは、ざっくり言うとアプリ内で、ブラウザ（IE）を立ち上げるような形式に対し、
Office OnlineのOfficeアドインは、iframeで起動します。
もし、サードパーティ(GoogleやOffice365やGitHubなど)のアクセストークンを使用して、サードパーティの情報を使用したアプリを開発しようと考えた場合。
iframeなので、つまりサードパーティ(GoogleやOffice365やGitHubなど)のログイン画面などは、パネル内で表示されないことになります。
一方で、クライアント版では普通に表示されます。
なので、最初にクライアント版でログイン画面が表示され、よしこのままOnline版もやっちゃおう！となった場合、
このことを知らないと、Office Onlineでは確実にエラーになってしまいます。
回避方法もあるが、IEで以上に面倒なことになる
これを回避するために、office-js-helpersという仕組みも用意されています。
これは、ログイン画面をOfficeアドイン内ではなく、ダイアログを起動してログイン画面を表示する仕組みです。
上記のように、アドインとは別のダイアログを起動します。
未ログインの状況であれば、そのままログイン画面が表示され、IDパスワードを入力し、ログイン完了したら、ダイアログを自動で閉じて、アドイン側にトークンを受け渡す、という仕組みです。
ダイアログ内で表示するので、iframeの制約にも引っかかることなく、ログインを行うことができます。
これを使えばいいじゃないか、と思うかもしれませんが、今度はIEの場合で、「信頼済みサイト」の問題が出てきます。
「信頼済みサイト」の問題とは、簡単にいうと「ブラウザ内のすべてのサイトを、同一のセキュリティゾーンに入れなければいけない」、という制約です。
例えば、Office365にログインを行ってアクセストークンを取得し、Office365の情報を取得するようなアプリを考える場合。
この場合、以下のページの信頼済みサイトを揃える必要があります。
「Office OnlineのSharePointサイト」（https://foobar.sharepoint.com）
「アドインの本体のサイト」（https://foobar1234567.azurewebsites.net）
「Office365ログインページ」(https://login.microsoftonline.com)
「揃える」とはすなわち、
「すべて信頼済みサイトに入れる」か、「すべて信頼済みサイトに入れない」の、どちらかです。
これが揃っていないと、エラーが発生します。
そしてこれが厄介なのが、『いつの間にか、Office OnlineのSharePointサイトが追加されていることがある』ということです。
Office365をいじっているときなのか、クライアント版のOfficeにアプリのURLを追加した場合なのかは分かりませんが、気付いたらこのSharePointサイトが信頼済みサイトに追加されているときがあります。
そうなると、アプリが起動できなくなります。その場合には、残りのサイトを追加する必要があります。
そして、この一連の流れを、アプリを利用する利用者にやってもらわなければなりません。
会社でポリシー配布などを行っていればいいですが、そうでない場合でIEで実行を行う場合に、すべての利用者に、この信頼済みサイトの追加をやってもらわなければなりません。・・・まあ、超面倒ですね。
対策としては、「IEをサポートから切り捨てる」というのも有りかもしれないですね笑
Windows10のIE11で、データのやり取りが正常に動作しない場合がある
上記のダイアログ形式で、アクセストークンのやり取りをするわけですが、ここまでやっても、正常に動作しないことがあります。
それはどうも、Windows10の、一定時期より古いIE11だと、正常に動作しないようです。
かんたんに調査してみたでのすが、
- ダイアログ同士のデータのやり取りは、標準ではjavascriptのpostMessageで行う
- だが、IEではpostMessageに対応していないので、localStorageの監視によりデータをやり取りしている
- だがだが、Windows10のIE11だと、上記の「IEかどうか」という条件が正常にしておらず、うまく動かない（Office.jsのバグ？）
- そのため結果的に、一部のWindows10のIE11だと動作しない
ということで、Windows10のIE11だと、うまく動かないことがあるようです。
なので、最終的な結論としては、Online版はIE非推奨にしてしまうのが一番ですね。（切実）
まとめ
Officeアドインはどうにも伸び悩んでいます。
その背景は多々ありますが、一つはこの地雷の多さにあると、私は思っています。
それでも、Officeアドインで開発する！という事になった場合、まずはこの記事を読んでいただき、どんな地雷があるかどうか、知ってもらえると嬉しいです。
コメントを残す