Officeアドインを、Office Onlineで実行するための手順です。

「Office Online」でOfficeアドインを実行するためには、アプリ本体となるhtmlファイル・各種プログラムをサーバーにアップロードしなければいけない・・・と考えがちですが、実はそんなことはなく、localhostにアプリを配置したまま、アプリを実行し、デバッグ・検証することができます。
以下、その手順を記載します。

前提条件

執筆時環境・バージョン

• Windows10
• Microsoft Office (Microsoft365版) ビルド13530.20376
• Edge 88.0.705.53(Chromeでも可)
• VSCode 1.52.1
• Live Server v5.6.1

前提

• すでにOfficeアドイン(クライアント版)を、ローカル環境で動作するための手順が整っていること

実行環境

• ローカル環境URL：https://127.0.0.1:5500 （Live Server）

必要ソフトウェア

• OpenSSL ※自己証明書を作るために必要です。証明書がすでにあったり、別の方法で証明書が作成可能な場合は、不要になります。

手順

自己証明書作成

Office Onlineでは、https通信で実行する必要があるようです。
そのため、証明書を作成します。すでに証明書がある場合は不要です。

• 証明書を配置するフォルダで、以下のコマンドを実行します。
  ※Windows用です。OpenSSLが"C:\Program Files\OpenSSL-Win64"にリリースされている前提です。その他諸々は、自己責任でお願いします。

"C:\Program Files\OpenSSL-Win64\bin\openssl.exe" req -x509 -newkey rsa:4096 -sha256 -nodes -keyout vscode_live_server.key.pem -out vscode_live_server.cert.pem  -subj "/CN=example.com" -days 3650

• これで、コマンドを実行したフォルダに、証明書"vscode_live_server.key.pem", "vscode_live_server.cert.pem"の2つが作成されます。

VSCode設定

• VSCodeを開き、アプリ本体(htmlファイルなど)のあるフォルダを開きます。

• Live Serverをhttpsで開くための設定を行います。
  VSCodeのメニューより、「ファイル」→「ユーザー設定」→「設定」を選択します。

• 「ワークスペース」タブの、「拡張機能」→「Live Server Setting」を選択します。

• Settingsの「Https」項目を探し、値を変更します。
  • enable : true
  • cert : 作成した証明書のcertファイルのフルパス
  • key : 作成した証明書のkeyファイルのフルパス
  • passphase : 空欄

• 右下の「Go Live」ボタンをクリックします。

• ブラウザで、証明書の確認メッセージが表示されますので、一旦承認し、アクセスを許可します。（この過程がないと、アプリが起動しませんでした）

マニフェストファイル修正

• マニフェストファイルのURLが、httpになっている場合、httpsに修正してください。デバッグとして必要な最低限は、以下の2箇所です。

①DefaultSettings->SourceLocation

②Contoso.Taskpane.Url

Office Onlineでアプリ実行

• そのブラウザのまま、Microsoft365などで、Office Onlineを開きます。
  ※キャプチャではWordですが、Excel・PowerPointなどでも手順は一緒なはずです。OneNoteやOutlookは同じか怪しいかも

• メニューの 「挿入」をクリックし、「アドイン」 を選択します。

• 「個人用アドイン」の中の「個人用アドインの管理」をクリックし、「マイ アドインのアップロード」をクリックします。

• これで、マニフェストファイルがアップロードされます。クライアント版Officeと同じような手順でアプリを実行することで、アプリが読み込まれます。

localhostで実行されている環境にも関わらず、アプリが読み込まれました。
※もちろん、Live Serverを実行している端末以外で、Office Onlineを起動しマニフェストファイルを読み込んでも、アプリは実行されませんので、ご了承ください

デバッグする

いろんな場所で記載していますが、OfficeアドインはWebアプリケーションです。そのため、ブラウザのデバッグ機能をそのまま実行できます。

• Edgeの場合、F12をクリックし、「ソース」タブを開きます。

• 左リストの中の、「ぺージ」から、「top」→「WebApplicationFrame」→「{"baseFrameName:....}」→「ローカル環境のURL(127.0.0.1:5500)」と開くことによって、作成したhtmlやスクリプトが開けます。

• 後は、各々で作成したコードにブレークポイントを置いて、実行することで、デバッグが実施できます。

まとめ

クライアント版のOfficeの方が安定感がありますが、前回の記事で書いたように、どうにも環境依存で動く・動かないがあるようです。
この手順なら、ごく普通のブラウザで動作・デバッグ可能ですので、場合によっては、Office Onlineでの開発も検討してみてください。

参考

https://docs.microsoft.com/ja-jp/office/dev/add-ins/testing/sideload-office-add-ins-for-testing
https://qiita.com/ma2shita/items/297c812a6cd09b5e82c8

Officeアドイン（クライアント）のデバッグを、VSCodeで実行するための手順です。

Visual Studio 201XのOfficeソリューションであったり、nodeを使用した環境であれば、デバッグの方法についてはちょいちょい出てくるのですが、それ以外の環境で、VSCodeを使用した手順がなかなか出てこなかったので、まとめました。

今回はサーバーにLive Serverを使用していますが、XAMPP、IIS、Apacheなど、環境は何でも良いと思います。

また、どういうわけか同じ手順を踏んでいても、なぜかデバッグが正常に動かなかったり、ブレークポイントに引っかからなかったりということが発生していました。
そのため、もしこの手順でデバッグが正常に動かない場合は、お手数ですが、端末の再起動、VSCodeの再起動など、お試しください。
それでも駄目なら、なにか別の理由があると思いますが、今は分かりません。ごめんなさい。

前提条件

執筆時環境・バージョン

• Windows10
• Microsoft Office (Microsoft365版) ビルド13530.20376
• Edge 88.0.705.53
• VSCode 1.52.1
• Microsoft Office Add-in Debugger v0.2.0
• Live Server v5.6.1

前提

• すでにOfficeアドイン(クライアント版)を、ローカル環境で動作するための手順が整っていること

実行環境

• ローカル環境URL：http://127.0.0.1:5500 （Live Server）

手順

• スタートメニューで、「Visual Studio」と入力すると、「Visual Studio Code」が表示されます。

• そこで、「管理者として実行」をクリックします。 (※)

• 正常に開けた場合、VSCodeのタイトルに[管理者]と表示されます。

• 左メニューの「拡張機能」で、「Microsoft Office Add-in Debugger」で検索し、インストールします。
  

• 左メニューより「実行」を選択し、「launch.jsonファイルを作成します」リンクをクリックし、「Office Addin」を選択します。
  

• launch.jsonファイルが作成されます。
  

• launch.jsonに、行を追加します。※最初の行に「,」を追加してください
  ※ここで、"url"の値の"?"の前に、「/」を付けてください。これが無いと、正常に動きませんでした。
  ※逆に、「/」があると動かないケースもあるかもしれません。この値は、有る無しで切り替えてみてほしいです。

        ,
        {
            "type": "office-addin",
            "request": "attach",
            "name": "Attach to Office Add-ins",
            "port": 9222,
            "trace": "verbose",
            "url": "http://127.0.0.1:5500/?_host_Info=Word$Win32$16.01$ja-JP$$$$0",
            "webRoot": "${workspaceFolder}",
            "timeout": 3000
          }

• VSCodeで、任意の場所にブレークポイントを置きます。
  

• Live Serverで実施する場合、右下の「Go Live」ボタンをクリックします。 (※)
  

• Wordを起動し、Officeアドインを開きます。 (※)
  

• VSCodeに戻り、左メニューの「実行」をクリック後、左上の「Launch」と書かれている再生ボタンの右の一覧をクリックし、「Attach to Office Add-ins」を選択します。 (※)
  

• そのまま、左上の「Launch」と書かれている再生ボタンをクリックします。 (※)
  正常にデバッグが完了すれば、VSCodeのページ上部に下記キャプチャのような表示が行われます。
  

• Wordのアプリのjs処理を実行してみます。 (※)
  

• VSCodeで、ブレークポイントで停止しました。
  

再度、デバッグを実施する場合

端末の再起動などで、再度デバッグを実施する場合は、手順に(※)と記載の部分のみ、実施を行ってください。

やっぱり動かない場合

どうもこのOfficeアドインのデバッグは不安定なようで、どうやっても正常に動作しない、というご報告をいただいていました。
そのため、Office Onlineでの動作手順も、今後記事にしようと思っています。気長にお待ちください。

実装方針

MSのサイトに、node.jsとASP.NETのサンプルはすでにあるので、今回は別の言語で実装することにします。
今回は最近愛してやまない、PHPのLaravelで実装しました。Laravelサイコー。

なお、基本的には以下のドキュメントに記載の内容の後追いになります。こっちと自分の記事を読みながら検証するのがベスト。
https://docs.microsoft.com/ja-jp/office/dev/add-ins/develop/sso-in-office-add-ins

https://docs.microsoft.com/ja-jp/office/dev/add-ins/develop/register-sso-add-in-aad-v2

準備・設定

前提

• 今回構築するLaravelサイトの情報は以下になります。
  http://127.0.0.1:8000
  ※実際に公開する場合は、「127.0.0.1:8000」を修正してください
  ※また、この記事を書き始めた当初、「localhost:9000」と思い、キャプチャを作成し始めてしまいました。そのため、キャプチャ内に「localhost:9000」があった場合、「127.0.0.1:8000」に修正をお願いします。

• Laravel5.6で構築しております。

Office365インストール

Office365のクライアント版を、Office365のサイトからインストールします。

Azure AD v2設定

• 以下のAzureポータルページにアクセスし、Office365のアカウントでサインインします。
  [https://go.microsoft.com/fwlink/?linkid=2083908]

• 「アプリの登録」より、「新規登録」をクリックします。
  

• 以下のように入力し、「登録」をクリックします。
  

• アプリケーション (クライアント) IDとディレクトリ (テナント) IDをコピーしておきます。（あとで使用します）
  

• 「証明書とシークレット」をクリックし、「新しいクライアント シークレット」をクリックして、クライアントシークレットをコピーします。(こちらも後で使用します)
  

• 「API の公開」→「設定」をクリックし、値に以下を入力します。
  api://(Webサイトのドメイン)/(先ほどコピしたアプリケーションID)
  例： api://127.0.0.1:8000/f4255842-2ac6-4b01-b8a6-aaaaaaaaaaaa

• 「Scopeの追加」をクリックし、以下のように入力します。
  ※スコープ名に「access_as_user」、同意できるのは誰ですかを「管理者とユーザー」と記入し、後は適当に

• 「承認済みのクライアント アプリケーション」下の「クライアント アプリケーションの追加」をクリックし、
  「クライアントID」に以下の3つを入力し、「承認済みのスコープ」チェックを行い、「アプリケーションの追加」をクリックします。
  (Office系の設定値らしいです)
  d3590ed6-52b3-4102-aeff-aad2292ab01c
  57fb890c-0dab-4253-a5e0-7188c88b2bb4
  bc59ab01-8403-45c6-8796-ac3ef710b3e3

• 「APIのアクセス許可」をクリックし、[Microsoft Graph] を選択してから [委任されたアクセス許可] を選択します。
  その後、以下にチェックを行い、「アクセス許可の更新」をクリックします。
  offline_access
  openid
  profile

最後に、「既定のディレクトリ に管理者の同意を与えます」をクリックします。

以上で、Azure AD v2側の設定は完了です。

Laravel開発

Laravelの開発を行っていきます。
※composerをインストールしている前提です。composerの説明は割愛します。

• インストールするフォルダで、コマンドプロンプトなどで、以下のコマンドを実行します。
  実行後、officejs_sso_laravelフォルダにcdします。
  composer create-project "laravel/laravel=5.6.*" officejs_sso_laravel

• 以下のリポジトリより、phpファイルをダウンロードします。
  https://github.com/hirossyi73/office-js-sso-laravel

該当ファイルを、Laravelディレクトリに上書きます。

• .envファイルに、以下の値を記入します。
  CLIENT_ID=(コピーしたアプリケーションID)
  CLIENT_SECRET="(コピーしたクライアントシークレット。ダブルクオーテーションで囲むことを推奨)"
  SCOPE="offline_access openid profile"
  TENANT=(コピーしたテナントID)

• 以下のコマンドを実行します。
  php artisan serve

これで、以下のURLでサーバーが起動します。
http://127.0.0.1:8000

Officeアドイン設定

• githubより、マニフェストファイルをダウンロードします。

https://github.com/hirossyi73/office-js-sso-laravel/blob/master/Office-Add-in-Laravel.xml

• ダウンロードしたマニフェストファイルを開き、135行目以降のWebApplicationInfo以下の内容を修正します。

    <WebApplicationInfo>
      <Id>(アプリケーションID)</Id>
      <Resource>api://(ドメイン)/(アプリケーションID)</Resource>
        <Scopes>
            <Scope>openid</Scope>
            <Scope>offline_access</Scope>
            <Scope>profile</Scope>
        </Scopes>
    </WebApplicationInfo>

• マニフェストファイルを、Officeのセキュリティ設定で「カタログ URL」に設定したパスに配置します。

• PowerPointを開き、アドインを起動します。

• 正常終了すると、このようにトークンが取得されます。

• このうち、
  • アドイントークン：OfficeのSSOから取得したトークンです。
  • ユーザー名：アドイントークンから取得したログインユーザー名です。
  • Eメール：アドイントークンから取得したメールアドレスです。
  • Graphアクセストークン：アドイントークンを使用し、PHP(Laravel)側で取得したMicrosoft Graphトークンです。もちろん、このトークンをMicrosoft Graphに使用すれば、情報を取得できます。
  • Graphリフレッシュトークン：アドイントークンを使用し、PHP(Laravel)側で取得したMicrosoft Graphのリフレッシュトークンです。

解説

ソース単位でご説明します。

アドイントークン取得

以下の内容で、アドイントークンを取得しています。

//  app.js
(function(){
    // 初期化処理
    Office.onReady(function(info) {
        if(!Office.context.auth.getAccessTokenAsync){
            log('Office.context.auth.getAccessTokenAsync not supported');
            return;
        }

        // 認証実行
        Office.context.auth.getAccessTokenAsync(function (result) {
            if (result.status === "succeeded") {
                // Use this token to call Web API
                var ssoToken = result.value;
                $('#addin_token').val(ssoToken);

                // decode user info
                var decoded = jwt_decode(ssoToken);

                $('#username').val(decoded.name);
                $('#email').val(decoded.preferred_username);

                getGraphToken(ssoToken);
            } else {
                if (result.error.code === 13003) {
                    // SSO is not supported for domain user accounts, only
                    // work or school (Office 365) or Microsoft Account IDs.
                } else {
                    // Handle error
                }

                log('error ' + result.error.code);
            }
        });
    });
})();

ポイントは「Office.context.auth.getAccessTokenAsync(function (result) {」で、この関数で、PowerPointのアプリケーションからSSOで、アドインのトークンを取得しています。
トークンはJWT形式なので、「//decode user info」の部分で内容を解析し、名前とメールアドレスを取得しています。

Microsoft Graphトークン取得

以下の内容で、Microsoft Graphトークンを取得しています。

//  app.js

/**
 * Microsoft Graphのトークンをサーバーサイドから取得
 * @param string apptoken アドイントークン
 */
function getGraphToken(apptoken){
    var CSRF_TOKEN = $('meta[name="csrf-token"]').attr('content');

    $.ajax({
        url:'./graphtoken',
        type:'POST',
        data:{
            'apptoken':apptoken,
            '_token' : CSRF_TOKEN,
        }
    })
    // Ajaxリクエストが成功した時発動
    .done(function(data){
        $('#graph_token').val(data.access_token);
        $('#graph_refresh_token').val(data.refresh_token);
    })
    // Ajaxリクエストが失敗した時発動
    .fail(function(data){
        log('Graph token error : ' + JSON.stringify(data));
    })
    // Ajaxリクエストが成功・失敗どちらでも発動
    .always(function(data){
    });
}

// IndexController.php
    /**
     * Graphのトークン取得
     *
     * @return void
     */
    public function graphtoken(){
        $apptoken = request()->get('apptoken');

        // ホントはここで検証を行う

        // Graphのアクセストークンを代理フローで取得
        // https://docs.microsoft.com/ja-jp/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
        $client = new \GuzzleHttp\Client;

        $res = $client->request(
            'POST',
            'https://login.microsoftonline.com/common/oauth2/v2.0/token',
            [
                'form_params' => [
                    'grant_type' => 'urn:ietf:params:oauth:grant-type:jwt-bearer',
                    'client_id' => env('CLIENT_ID'),
                    'client_secret' => env('CLIENT_SECRET'),
                    'assertion' => $apptoken,
                    'scope' => env('SCOPE'),
                    'requested_token_use' => 'on_behalf_of',
                ]
            ]
        );

        $list = json_decode($res->getBody()->getContents(), true);
        return $list;
    }

検証をサボってますが、本番環境では検証、ちゃんとやってくださいね。
この内容によって、代理フローを使用し、Microsoft Graphトークンを取得するわけです。

まとめ

長くなってしまいましたが、以上でSSOを使用したサンプルは完了します。
今後実装を検討される方は、是非参考にしてみてください！

Officeアドインを開発時に気を付けなければいけない地雷まとめの「Officeのログイン者情報を、Officeアドインで取得することはできない」にも書いたのですが、Officeアドインの安定版では現在、「Officeにログインしているユーザー」を取得することはできません。

どう考えても取れそうな「佐藤 裕」という情報が、残念ながら取得は出来ないのです。安定版では。

そのため、もし「Officeアドインで、Office365のユーザー情報を取得してゴニョゴニョする」というアプリを検討していたとしても、ユーザーに再度ログインを強要する必要があります。
これがクライアント版のOfficeならまだ良いのですが、Online版まで考えると本当に地獄。
アプリがiframeで実装されているがゆえに、認証できず、dialogを表示する必要が出てしまいます。
※これもOfficeアドインを開発時に気を付けなければいけない地雷まとめの「認証が絡む場合、Office Onlineには本当に注意」を参照

しかし、これがPreviewでは、一部できるようになります！
Office系、それもAzure AD v2でのログインに限り、SSOとして、Officeのアプリにログインしている情報（正確にはアクセストークン）を取得できるようになるわけです。
そのため、ユーザーはわざわざ2回目のログインを行う必要がなくなるわけですね。

今回は、この「Office アドインのシングル サインオン」の概要をご紹介します。
検証はまだなので、触りのみとなってしまうことをご了承ください。

概要

基本的にはこちらの公式サイトをご参照ください。
https://docs.microsoft.com/ja-jp/office/dev/add-ins/develop/sso-in-office-add-ins
キーポイントをかいつまんで解説します。

流れ

※引用：https://docs.microsoft.com/ja-jp/office/dev/add-ins/develop/sso-in-office-add-ins

ざっくり流れをまとめると、以下のとおりです。

• Officeアプリ(各開発者が開発するWebアプリ)内のjsファイルで、getAccessTokenAsync関数を実行する

• getAccessTokenAsync内の処理で、Officeプログラム（ExcelやWordの本体）に、現在ログインしているユーザー情報を取得するよう要求する

• Officeプログラムにログインしていない場合、ログインするようユーザーに要求するダイアログを表示する

• Officeプログラムは、Azure AD v2エンドポイントから、現在のユーザーのアドイン トークンを取得する

• Officeプログラムから、getAccessTokenAsync関数の処理として、Officeアプリに、アドイントークンを返却する
  →アドイントークン(JWT)を解析して、ログインユーザーのメールアドレスなどを取得する

ユーザー情報などを取得するのみであれば、ここまでで処理は終了なのですが、Microsoft Graphなども絡める場合、以下の処理も必要になります。

• Officeアプリから、サーバーサイドにアドイントークンを送信する

• サーバーサイドで、Microsoft Graphなどで使用できるアクセストークンを取得し、Officeアプリに返却する

このような処理になります。

注意点

ここからは、現在分かっている注意点を記載します。やはり地雷は多し。

Office Insiderに参加が必要

2019/05/21現在、プレビュー版のみ対応であるため、「Office Insider」に参加する必要があります。
参加した上で、プレビュー版のOfficeをインストールする必要があります。

Office2013や2016には非対応

これがとっても大事ですね。
SSOは「IdentityAPI」という要件セットが必要で、これはOffice2013や2016は非対応です。恐らく今後も。
なので、このSSOを対応させるのであれば、2013や2016を切り捨てる必要がありますね。

サーバーサイドの実装が必要

これは実際のサンプルコードで実装した時に解説予定なのですが、Microsoft Graphなどのトークンを活用したい場合には、サーバーサイドの実装が必要になります。
通常のhtmlとjavascriptだけのアプリを開発しよう！と思っても、それはNGなんですね。vueとかReactとかも多分NG。

今回取得できるトークンは、あくまでも「アドイントークン」で、Microsoft Graphのアクセストークンではありません。
Microsoft Graphのアクセストークンを取得する際には、別途サーバーサイドの処理が必要、ということを覚えておいてください。

まとめ

このように、どうしても限定的な範囲にはなってしまいますので、これはOfficeストアのような全体公開向けのアプリではなく、組織内でのアプリの方が向いているかもしれないですね。
また、現在はプレビュー版なので、いずれにせよ正式版に採用は難しいです。

それでもメリットは十分にあります。Office365前提のアプリであれば、非常に便利な機能になることは間違いないです。

実装の検証と、具体的な解説は次回行う予定です。ぜひお待ちください。

「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アドインで開発する！という事になった場合、まずはこの記事を読んでいただき、どんな地雷があるかどうか、知ってもらえると嬉しいです。

Officeアドインで、設定値を保存したい場合。
例えば、アプリの表示言語を変更・設定できるようにしたい場合、 設定値を保持することが出来れば、アプリを再起動した場合でもわざわざ再設定する必要が無くなって便利ですね。

このような機能を実装したい場合、果たしてどのように開発すればいいでしょうか？
その方法について、実は2つの方法があります。
その2つの方法はどのようなものか？ その使い分けも含め、今回はその開発方法について解説します。

■解説

上記でも記載した通り、Officeアドインで設定値を保存する方法は主に2つあります。
それぞれメリット・デメリットあるので、それぞれ見てみましょう。 　

①Officeアドインの関数"Settings.set"を使用する

"Office.context.document.settings.set"というメソッドを使用することで、 Officeのドキュメントに名前/値のペアとして設定値を格納します。
参考：https://msdn.microsoft.com/ja-jp/library/office/fp161063.aspx

イメージとしては、Officeファイルに名前/値のペアとして設定値を格納することになります。

Officeファイルに格納するので、保存時とは別のOfficeファイルを開いた場合は、その設定値を読み込むことは出来ません。別の値として扱われます。

一方で、別ユーザーが同じファイルを読み込んだ場合は、すでに保存済みの設定値を読み込むことができます。
これはファイルそのものに設定値を書き込みしているので、どのユーザーが開いても同じ設定値を利用することが出来るのです。

②HTML5の機能"LocalStorage"を使用する

LocalStorageは、HTML5で新たに追加された機能です。
ブラウザ側に名前/値のペアとして設定値を格納する事ができます。
http://wp.tech-style.info/archives/742

「OfficeなのにHTML5の機能を利用できるの？」と思う方もいるかもしれませんが、 OfficeアドインはれっきとしたWebアプリケーションなので、問題なくLocalStorageを使用できます。
OfficeアドインでLocalStorageを使用した場合、そのアプリ内では共通して同じ値として管理されます。
つまり、別のOfficeドキュメントでアプリを起動した場合でも、同じ設定値を保存・読込することが出来ます。わざわざ保存し直す必要がなくて便利ですね。

しかし、別ユーザーが同じファイルを開いたとしても、同じ設定値を使用することは出来ません。 そこはご注意下さい。

③結局どっちがいいの？

ぶっちゃけ用途によります。 以下、簡単にまとめてみました。

※Settings.set関数
・ドキュメントに設定値を格納する
・同じファイルを開いた場合、どのユーザーであっても同じ設定値を保存・読み込むことができる
・別のファイルを使用した場合、設定値は共有されない
・Excelセルに記載された金額・人物名など、各Officeファイルに紐付いた値を保持しておきたい場合におすすめ

※LocalStorage
・ブラウザに設定値を格納する
・保存時とは別のファイルを開いた場合でも、設定値を共有することができる
・別のユーザーが保存時のファイルを開いた場合、設定値は共有されない
・アプリの表示言語など、実行したユーザーごとに異なる設定を保持しておきたい場合におすすめ

開発したいアプリの用途によって使い分けることをおすすめします。 もちろん両方使用することもアリでしょう！ あなたの開発にお役立て下さい。

■おわりに（自己紹介）

まだまだマイナーながら、無限の可能性を秘めた「Officeアドイン」の解説記事を少しずつ執筆しています。
もっと詳しく知りたい！といったことや、この内容を解説して欲しい！ということがありましたら、 コメントなどにてお気軽にご連絡ください。

その1
その2
前々回でOfficeアドインの紹介、およびメリット。 前回は、Officeアドインの現状抱える課題、デメリット。 これらについてまとめてきました。
特に前回は、ある意味致命的ともいえる「Officeでやる必要ない」という欠点についても紹介しました。
……こんな事言ってしまって、今回ひっくり返せるのかすごく心配ですが(ﾟoﾟ;笑

さて！連載最終回となる今回は、「Officeアドインの生きる道とは」をテーマにまとめていきたいと思います！
VBAほどの柔軟さは無く、Webアプリであればブラウザで十分。 そんな中で、Officeアドインが今後広まっていくにはどうすればいいか？
一筋の光となるかもしれない、そんな提起をしようと思います。

※今回は今までより更に、私見が大量にあります。 その点ご理解いただける方のみ続きをお読みください。

これがOfficeアドインの生きる道

結論から言いましょう。それはズバリ、
「そのアプリでしか出来ない価値を提供する」 「Officeの機能を拡張する事を徹底追及する」** という事です！

………？(´･ω･`) なに当たり前の事を言ってるんだ……？と思う方もいるでしょう、多分笑
どういう事か？今からこれを説明していきますが、その前に。
前回の課題で挙げた、「Officeでやる必要ない」。
これがどうして発生するのか、もう少し深堀りして考えてみます。

失敗パターン

前回の記事の例ですと、「家計簿サイトをアプリで実行し、内容をExcelに出力できるアプリ」。これを作ることを想定します。

①すでに完成されている家計簿サイトをアプリで呼び出して、
②1ヶ月に1回ぐらいの頻度で内容を出力する。こんなフローになります。

……もうお分かりだと思いますが、Officeアドインである必要がまったくありません。
①は通常のWebブラウザ、またはスマホあたりで登録すればいいし、
②もやっぱり、WebアプリケーションでExcelファイルを作成する仕組みの方が、よっぽど柔軟性があるはず。
改めてこういう風にまとめると、Officeアドインの必要が無いことが良く分かると思います。

ただ現実の話、今完成されているサービス・アプリを見て、
「家計簿→Excel→Officeアドイン…… あっ！これOfficeアドインに向いてそう！！」と思い、開発に飛び付いてしまうと、きっと失敗します。
何故ならば、そのサービスは大抵がすでに完成されていて、Officeアドインである必要がないから。
開発をする前に、本当にOfficeアドインでやる必要あるか？という点を、改めて改めて改めて考慮してみてください。

改めて、Officeアドインの生きる道

以上のように、失敗パターンをまとめてみました。
それを踏まえた上で、もう一度Officeアドインの生きる道である 「そのアプリでしか出来ない価値を提供する」「Officeの機能を拡張する事を徹底追及する」 を見てみましょう。

普段のOffice業務を中心軸に

失敗パターンが「普段のWeb業務をOfficeでやろう」だとするならば、その逆です。
「普段のOffice業務をアプリで補助する」
これが唯一の、当たり前とも思える、Officeアドインを開発する上で唯一の最大の鍵だと思います。**

皆さんの普段のOffice業務は何でしょうか？ プレゼン資料作成？設計書作成？勤怠管理？経費精算？
色んな業務があるはずですが、その普段やっている業務を補助するためのアプリを作ることが超大切。

×Officeアドインの為にOfficeを開かせよう（絶対めんどくなる）
○OfficeをサポートするOfficeアドインを使わせよう
この考え方を持ち続けて設計・開発すること。
そして、開発者がこれを常に意識して、開発したアプリがOfficeストアに公開され続ければ、皆さんの普段の業務を網羅する、「なんか便利なものがあるらしいぞ」と広がっていくことになるでしょう。
Microsoftもきっと、キラーアプリを待ち望んでいるんじゃないかと思います。
どんな人、どんな業務でも使える、Microsoftきってのオススメアプリを！ そんなアプリを、あなたの手で開発してみましょう。 　

まとめ

あくまでもOfficeアドインは、Officeのアプリなんです。Webアプリケーションとは基本はOffice。
Officeを使った業務を活かすアプリ、これを作れば、きっとOfficeアドインも、作ったあなたも、知名度が変わってくるでしょう。
貴重なビジネスチャンスを作っていけるはずです！

前回の記事で、Officeアドインとは何か、そしてOfficeアドインのメリットについて説明しました。
それだけのメリット、そして「Office」という非常に知名度のあるベースがありながら、
現状ではOfficeアドインが「成功している」とはそこまで言えません。**

なぜOfficeアドインがそこまで広がらないのか？
連載2回目となる今回は、Officeアドインが現状抱える問題点、デメリットについてまとめていきます。
※あくまでも個人の見解です！Microsoft様およびOfficeを中傷する意図はありませんのでご了承下さい

Officeアドインのデメリット

知名度が低い

まず、「Officeアドインというものがあるよ」「Office上でアプリが動くんだよ」ということを知っている人は果たしてどれだけいるのでしょうか？
「Office」の知名度は抜群でも、「Officeアドイン（ないしは「Officeで動くアプリ」ということだけでも）」の知名度はかなり低いでしょう。
「Officeアドイン」というものがあることを知らなければ、ストアに多数アプリがあったとしても、使うことはきっと無いはずです（知らない訳だし）。

ストア掲載のアプリが少ない

Officeアドインが動くようになったのは、Office2013から。
詳しく開始日までは分かりませんが、単純計算で現在（2016年7月）から3年が経過しています。
しかし、現在Officeストアに掲載されているアプリ数は、決して多くありません。
2016年7月1日現在、Excel用アプリケーションは263件、Outlook用アプリケーションは170件でした。そして多くが海外製です。
せっかくOfficeアドインの存在を知っても、欲しいアプリがなかなか無い…というのが実情です。
（書いていて、Outlook用アプリケーションが170件しかないことに(゜o゜;でした）

【開発者向け】出来ることが少ない

VBAの感覚でOfficeアドインを開発しようとすると、ほぼ確実に失敗します。
何故なら、Officeアドインで出来ることはかなり限られているからです。
最近はバージョンアップにより、可能なことも大分増えてきたようではありますが、特に初期の頃はかなり少なかったです。
例えばExcelで言うと、「セルB4に文字を書き込む」「指定のファイルパスのファイルを開く」といった、VBAでは当たり前のように出来ていたことが出来ませんでした。**
こうなってしまう原因で考えられるのは、Officeアドインが「Office365でも動く必要がある」ということだと考えています。
Office365で動かす以上、セキュリティはクライアント版より強固でなければいけません。
Office365とOffice2013と両対応するために、出来る機能が少ないのでは…と推察しています。

今では実装可能になったり、工夫次第で回避できるようになってはいますが、VBAの感覚で開発を始め、出来ることの少なさにぶち当たり断念する……といった方も多いとか。

わざわざアプリを使用する必要がない

これが自分の思う、最大の、そして致命的なデメリットです。
もちろん、すべてのアプリがそうとは思いません。ただ、わざわざOfficeを立ち上げて、アプリを起動する…といった流れをするだけの価値があるアプリ提供を、なかなかすることが出来ていないんじゃないか？と思います。

具体的に話しましょう。例えば、家計簿サイトのような便利なWebサイトを、Office上で実行できる。たまに、Excelの表に出力する。そんなアプリがあったとします。
Officeを立ち上げて、アプリを立ち上げて……って工程をやるうちに、ユーザーのあなたはきっと気付くはずです。
「これOfficeのアプリ使う必要無くね？」と。
端的に言えば、ブラウザで十分なことが非常に多いです。
ブラウザのWebアプリの方が、画面幅は圧倒的に広いですし、リンク先や機能の制限を受けることもありません。
Office（この場合はExcel）と連携できるメリットはありますが、基本的にOfficeと連携する回数は少ないので、Web上で「必要なときだけ」Officeファイルに出力とかすれば済んじゃうんです。
なので、既存のWebアプリをOfficeアプリにそのまま入れ込もうとすると、確実に罠に陥ることになります。
「Officeの必要性」という罠に。
「Office用のアプリ」なのに「Office使う必要ない」**という、ある意味致命的な矛盾を抱えているのが、多くのOfficeアドインの現状でしょうか。
Officeアドイン独自の価値を見出すものをなかなか生み出せていない、という風に見解しています。

どうすりゃいいんだ・・・

以上、Officeアドインが現在抱える問題点をまとめてみました。
本当はまだ何点かあって、例えば「Office2010だと動かない」「Webサーバー立てないと使えないから手軽じゃない」とか色々あるのですが、今回はこのあたりで。

さて、今回まとめたように、Officeアドインにはまだまだ発展途上です。
それでは、これからOfficeアドインが発展していくには果たしてどうすればいいのでしょうか？ 上記のような課題を抱えるOfficeアドインで、開発者はこれからどんなアプリを開発していけばいいのでしょうか？
次回はこの連載のシメ、「Officeアドインの生きる道とは」になります。ご期待ください！

Next

いちから学ぶOfficeアドイン – Officeアドインの生きる道とは（考察）

2016/04/01、Microsoftで「Build 2016」が開催されました。
https://build.microsoft.com/

そのBuild2016で、僕が以前から携わっている「Officeアドイン」についても大きな発表がありました！
おすすめの動画はこれらです。
https://channel9.msdn.com/Events/Build/2016/P554
https://channel9.msdn.com/Events/Build/2016/P561

Officeアドインの大幅な機能拡充により、今後利用ユーザー、開発ユーザーともに増えていくことが予想されます！（増えてほしいです）
しかし、Officeアドインの内容をまとめた記事や情報、そしてアプリそのものもかなり少なく。
興味を持った方が利用、もしくは開発しようにも、断念しかねないというのが現状です。

そこで今回は、Officeアドインのついての概要と、Officeアドインのメリット、そして現在抱えている課題とその解決策を、連載としてまとめていこうと思います。
連載第1回は、「そもそもOfficeアドインとは何か」、そして「Officeアドインのメリット」についてまとめていきます。

Officeアドインとは？

「Office アドイン（Office Add-ins、Office用アプリ、office.js）」は、「Microsoft Office 2013（以下Office）」以降で動作する、Officeの機能を拡張するWebアプリケーションです。
Office上で各アプリが起動し、ドキュメントと連携して情報をやり取りしたり、種類によってはメールを送信する等を行うことも出来ます。

Officeアドインには何個か種類があります。例えば、

Officeの右側でアプリが起動する「作業ウインドウ」形式。Word・Excel・PowerPoint等で動作します。

Excel上のシート右側でアプリが起動する「コンテンツ」形式。 Excelで動作します。

Outlookでアプリが起動する「メール」形式。見た目上は「作業ウインドウ」形式と変わりませんが、内部構造は若干異なります。
また、Outlookでは上記の画像のように、メールの本文上でアプリを開くことも出来ます。

このように、Office上でアプリを動作させることが出来るのが「Officeアドイン」の特徴です。

Officeアドインのメリット

Officeアドインを使用することによって、どのようなメリットがあるか？
独自の見解になりますが、これから解説していきます。
一般ユーザー向けと、開発者向けの2つのアプローチから解説します。

【一般ユーザー向け】アプリケーションをWeb上から簡単に導入できる

従来のOffice系プログラミングであるVBA・VSTOで、プログラムを追加したい場合、通常はWebブラウザを別途起動して、ファイルをダウンロード→実行、ということが多いと思います。
（他に方法あるかもしれませんが・・・あまり詳しくないです笑）
管理は大変ですし、ファイルごとにプログラムを実行しようと思ったらけっこう面倒です。

ですがOfficeアドインの場合、Office上のリボンにある「Officeアドイン」ボタンを押下することで、Officeストアからアプリを入手する事ができます


非常に手軽ですし、ボタンひとつで複数のファイルにアプリを挿入する事ができます。
「手軽さ」「誰でも実行できる」これは本当に便利です！

【一般ユーザー向け】Office365でも使用可能

Microsoftのクラウドサービスとして、『Office365』というものがあります。
Microsoftが全面に打ち出している（らしい）このOffice365では、「Word Web Apps」や「Excel Web Apps」など、ブラウザ上でOfficeが起動できるのですが、
このOffice365でも、アプリが起動できます！

クライアント版のOfficeを持っていない人でもアプリを実行できるので、アプリの敷居は低いと言えるでしょう。

【開発者向け】Webアプリケーションなので、HTML・CSS・Javascriptなど、汎用的な技術をそのまま流用できる

それまでのOffice系プログラミングであるVBA・VSTO等では、けっこうとっつきにくい開発言語や、言語が限定されていました。
VBAでは「Visual Basic for Applications」という比較的昔の言語、「VSTO」は「Visual Studio Tools for Office」という、限定された言語での開発となってしまいます。
しかし、Officeアドインは「office.js」というJavaScriptファイルを使用したWebアプリケーションです。Webアプリケーションなので、ナウでモダンでメジャーな言語・技術をいっぱい使用できます！
PHP、C#、RoR、node.js、Python、GO・・・ Typescript、coffeescript、Jquery・・・

情報が無数にある技術を使用できるので、非常に手軽に開発することができます！

Officeアドイン最高！！・・・と言いたいけれど

以上が、Officeアドインのメリットになります。
こうして書くと、すごく優秀なOfficeのパートナーになりそうですね！
これだけ優れてならば、きっとアプリが超充実！技術界隈も大盛り上がり！！
・・・となっている、そう思う方もいるかもしれませんが、
現実は、そう甘くはありません。
冒頭にも書いたのですが、このOfficeアドイン界隈は、 残念ながら2016年現在、そこまで栄えているとは言えない現状にあります。

「Microsoft」の「Office」という強力な2大双璧を持ちながら、なぜこのような現状なのか？
次回は、「Officeアドインの抱える欠点とは」ということをテーマとして、記事を書いていきたいと思います。

Next

いちから学ぶOfficeアドイン – Officeアドインの問題点とは