以下の投稿で、Azure Functions の基本的な使い方を紹介しましたが、1 点心残りがあります。

※URLが日本語になっている。。。ほんとすみません。。。

https://blogs.technet.microsoft.com/junichia/2017/01/27/azure-functions-から定期的に-microsoft-graph-にアクセスする/

それは以下の部分。

既存のコードを以下で上書きして下さい。コード内の Tenant ID、Client ID、Client Secret に先ほど控えた値を埋め込みます。Client Secret を生のまま埋め込むのはアレなので、本当はApp Service のパラメタに登録するのがよいのですが、ひとまずここでは生埋め込みでいっちゃいましょう。パラメタ登録についてはあとで説明します。

力尽きてこの部分を解説していませんでした。ということで、TIPS として書き残しておきます。

Client Secret のような、ソースコードに残したくない文字列は以下のような方法で簡易的に隠ぺいすることができます。

1. Azure Funtions の設定ページを表示

2. 左下の「Functions App の設定」をクリック

3. 「App Serviceの設定に移動」をクリック

4. 「アプリケーションの設定」をクリック

5. 右ペインをスクロールダウンして「アプリ設定」を表示

6. キーと値を設定と保存

7. ソースコードの ClientSecret 部分を以下のように変更

string clientSecret = "ARWgqtsCVcZ/CBOYQMTAxxxxxxxxxxxxxxxxxxxxxxxx";
↓

string clientSecret = ConfigurationManager.AppSettings["clientSecret"]

たったこれだけです。簡単ですね。

ただ、本当は Azure KeyVault を使って本格的に暗号化して隠してほしいわけです。

これについては次回。

一言でいえば、Azure Automation の”開発屋さん版”です（って、適当すぎて怒られそうw）。

Azure Automation は PowerShell スクリプトをクラウド上でジョブ化することができますが、Azure Functions は C#、F#、Node.js、Python、PHP Java などで書いたプログラムを WebJob として登録することができます。いずれも、サーバーを置くことなくジョブを実行することができる、いわゆるサーバーレスを実現するためのコンポーネントです。

PowerShell 好きの私的には Automation が好みではありますが、悔しいことに Functions のほうが高機能であることは否めません。何がいいって、入力や出力の定義が超簡単。これはAutomationにはない部分です。詳しくは以下の手順で。

Azure Functions の概要
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-overview

ためしに使ってみようかってことで、ここでは、Microsoft Graph にアクセスしてユーザー一覧を取得し、これを Azure Blob に保存するジョブを作成してみることにします。

Microsoft Graph にアクセスするので Azure AD 側の設定も必要になります、そこも含めて手順を書いておきますので参考にしてください。

1.  Azure Functions アカウントの作成

Azure Portal  の Marketplace で Function App を検索し、Function App をクリックしたら「作成」。

アプリ名等を入力して「作成」。アプリ名（ここでは GraphFromFunction.azurewebsites.net）は後でAzure AD にアプリ登録するときに使用します。

作成した Function App に移動すると、以下のようにApp Service（Functions の本体）、ストレージ、App Service プランが作成されていることがわかります。

App Service をクリックすると、Function App の簡易作成画面（クイックスタート）が表示されます。

今回は定期的に Microsoft Graph を実行するので「タイマー」を選択。言語は C#。

選択したら「この関数を作成する」をクリック。

初期画面が表示されたら、ためしに「実行」をクリックしてみる。

ログに以下のような出力がされれば、ひとまず正常です。太字部分はコード内の log.info() によって出力された文字列です。

2017-01-26T13:45:00.009 Function started (Id=db7524a6-c10b-4d9a-9e44-b61e86898aa0)
2017-01-26T13:45:00.009 C# Timer trigger function executed at: 1/26/2017 1:45:00 PM
2017-01-26T13:45:00.009 Function completed (Success, Id=db7524a6-c10b-4d9a-9e44-b61e86898aa0)

この関数はタイマーにバインドされているので、規定時間（5分）に1回、自動的に実行されます。

タイマーの間隔を変更するには、左側のメニューの「統合」をクリックします。

右下に「スケジュール」と書かれたフィールドがありますが、これが間隔を示しています。

設定の方法は以下を参照してください。

0 */5 * * * *

Azure Functions におけるタイマー トリガー
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-bindings-timer

2. Azure AD にアプリ登録する

Function App からいったん離れて、今度は Auzre AD 側の設定をします。実は、AppService の認証/承認の設定からでもできるのですが、今回は何が行われているのかを理解してもらうために面倒な手順で進めてみます。

なお、Azure AD について詳しく知りたい方は以下のリンクがおすすめです。

Azure AD ディレクトリの管理
https://github.com/Microsoft/azure-docs.ja-jp/blob/master/articles/active-directory/active-directory-administer.md

Azure AD は旧ポータルで操作するのがセオリーですが（ほんとかよ）、ここはあえて新ポータルでいってみましょう。

ポータルで「Azure Active Directory」を開いてください。

「プロパティ」をクリックすると「ディレクトリ ID」が表示されるので、これを控えておきます。あとから、ソースコード内で「Tenant ID」として使用します。

TenantID = c9687145-521f-42e6-xxxx-xxxxxxxxxxxx

次に「アプリの登録」をクリックすると、指定したテナントに関連づけられているアプリケーションの一覧が表示されます。

「追加」をクリックします。「アプリケーションの種類」は「Webアプリ/API」を選択。「サインオンURI」には、先ほど作成した Function App の URL(https://graphgromgunction.azurewebsites.net) を指定して「作成」をクリック。

先ほどのアプリ一覧に、今作成したアプリが追加されるので、クリックして設定画面を開きます。

「プロパティ」をクリックして表示された情報から「アプリケーション ID」を控えておきます。これはあとから「Client ID」としてソースコード内で使用します。

ClientID = e67fff1a-d912-4bf4-xxxx-xxxxxxxxxxxx

今度は「キー」をクリックします。

既定ではキーは作成されていません。

「機関」からキーの有効期限を選択し（ここでは「期限なし」）、「キーの説明」を適当に入力して「保存」をクリック。保存が完了すると「値」にキーが表示されるので、これを控えておきます。これがコード内で ClientSecret となります。キーが表示されたら、それを控えるまではページを移動しないでください。移動すると、安全のため二度と表示できなくなります。もしキーを忘れてしまったら、既存のものを消して新しくキーを作成すれば OK です。

ClientSecret = b/dmwx0WUnmljqxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

この作業で以下の3つの情報を収集することができました。

<Tenant ID> c9687145-521f-42e6-xxxx-xxxxxxxxxxxx

<Client ID> = e67fff1a-d912-4bf4-xxxx-xxxxxxxxxxxx

<Client Secret> = b/dmwx0WUnmljqxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

これらの値を、この後の作業で Function App 内に埋め込みます。

Azure AD の最後の作業として、アプリケーションにディレクトリへのアクセス権を与えます。

 アクセス権が無いと、正しいトークンを取得しても以下のようなエラーが発生します。

2017-01-27T04:29:02.895 {
  "error": {
    "code": "Authorization_RequestDenied",
    "message": "Insufficient privileges to complete the operation.",
       "innerError": { "request-id": "96e44229-5f66-4057-b9ea-f864b5013097",
       "date": "2017-01-27T04:29:01"
      }
    }
}

「必要なアクセス許可」をクリックしてください。既定では以下のようになっています。

アクセス権について詳しく解説はしませんが、このままではアクセスすることができません。

アクセス許可スコープ | Graph API 概念
https://msdn.microsoft.com/ja-jp/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes

今回は、Function App がユーザーのログオンを介さずに直接 Graph API にアクセスします。そのため、アプリケーションに対して直接権限を与える必要があります。規定では「委任されたアクセス許可」なので、ユーザーがログオンしないとアクセスすることができないのです。

API 一覧にある「Windows Azure Active Directory」をクリックすると、以下のように権限一覧画面が表示されます。「アプリケーションのアクセス許可」の中にある「Read directory data」を選択してください。既定で与えられている「Sign in and read user profile」は必要ないので外してしまいましょう。アプリケーションには余計な権限を与えてはいけません。「保存」をクリックして保存しましょう。

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

3. Function App の作成

Function App の設定画面に戻ります。

既存のコードを以下で上書きして下さい。コード内の Tenant ID、Client ID、Client Secret に先ほど控えた値を埋め込みます。Client Secret を生のまま埋め込むのはアレなので、本当はApp Service のパラメタに登録するのがよいのですが、ひとまずここでは生埋め込みでいっちゃいましょう。パラメタ登録についてはあとで説明します。

#r "Newtonsoft.Json"

using System.Net;
using System.Net.Http.Headers;
using Newtonsoft.Json;
using Microsoft.IdentityModel.Clients.ActiveDirectory;

public static async Task<String> Run(TimerInfo myTimer, TraceWriter log)

{
    log.Info($"C# Timer trigger function executed at: {DateTime.Now}"); 
   
    string resourceId = "https://graph.microsoft.com";
    string tenantId = "<Tenant ID>";
    string authString = "https://login.microsoftonline.com/" + tenantId;
    string clientId = "<Client ID>";
    string clientSecret = "<Client Secret>";
    //string clientSecret = ConfigurationManager.AppSettings["clientSecret"];

    log.Verbose("ClientSecret=" + clientSecret);
    log.Verbose("authString=" + authString);

    var authenticationContext = new AuthenticationContext(authString, false);
   
    //アクセストークン取得;
    ClientCredential clientCred = new ClientCredential(clientId, clientSecret);
    AuthenticationResult authenticationResult = await authenticationContext.AcquireTokenAsync(resourceId,clientCred);
    string token = authenticationResult.AccessToken;
    log.Verbose("token=" + token);

    var responseString = String.Empty;
   
    using (var client = new HttpClient())
    {       
        string requestUrl = "https://graph.microsoft.com/v1.0/users";
       
        HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, requestUrl);
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token);
        log.Verbose(request.ToString());
       
        HttpResponseMessage response = client.SendAsync(request).Result;

        responseString = response.Content.ReadAsStringAsync().Result; 

        log.Verbose(responseString);
       
    }

    return responseString;

}

※ こちらからダウンロードできます  https://github.com/junichia/Functions-Graph

残念ながら、このままでは動作しません。

ちょっと説明が面倒なのですが、今回は Microsoft Graph にアクセスするため、必要なモジュールを追加しなければなりません。モジュールによっては、コードの先頭に以下のように書くことで、自動的に Nuget から追加されます。

#r "Newtonsoft.Json"

これに関する詳細が知りたい方は、以下の「外部アセンブリの参照」を参照してください。

Azure Functions C# developer reference (Azure Functions C# 開発者向けリファレンス)
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-reference-csharp

残念ながら Microsoft Graph に必要なモジュール（Microsoft.IdentityModel.Clients.ActiveDirectory）は #r では追加することができません。

そこで、特別なファイルを作成してアップロードしてあげる必要があります。以下の  JSON ファイルを作成して、Project.json というファイル名で保存してください。3.13.8 は現時点での安定最新バージョンです。

Active Directory Authentication Library 3.13.8
https://www.nuget.org/packages/Microsoft.IdentityModel.Clients.ActiveDirectory/

Project.json

{
  "frameworks": {
    "net46":{
      "dependencies": {
          "Microsoft.IdentityModel.Clients.ActiveDirectory": "3.13.8"
      }
    }
   }
}

ファイルを作成して保存したら、これを Function App にアップロードします。

画面右上の「ファイルの表示」をクリックしてください。

以下のように3つのファイルが存在していることがわかります。現在のコードは「run.csx」です。

「アップロード」をクリックして、先ほど作成した Project.json をアップロードしてください。

アップロードが完了すると、Nuget から必要なモジュールが自動的にダウンロードされて組み込まれます。

これで動くようになったはずです。

コード画面の「実行」ボタンをクリックしてみてください。

ログに、以下の赤枠で囲んだようなJSON形式のデータが出力されていれば成功です。 

今回は、Graph の URL を以下のようにユーザー一覧を取得するように設定したので、Azure AD に登録されているユーザー一覧が取得できています。

https://graph.microsoft.com/v1.0/users

出力結果を JSON エディタ等で見ていただくと、以下のようなデータがユーザーの数だけ出力されています。

{
    "id":"deb57951-92af-4bc4-xxxx-xxxxxxxxxxxx","businessPhones":["+81 9099999999"],
    "displayName":"admin",
    "givenName":"admin",
    "jobTitle":"\u30a8\u30d0\u30f3\u30b8\u30a7\u30ea\u30b9\u30c8",
    "mail":"admin@pharaojp.onmicrosoft.com",
    "mobilePhone":"+81 9017xxxxxx",
    "officeLocation":"???-???????",
    "preferredLanguage":"ja-JP",
    "surname":"user",
    "userPrincipalName":admin@pharaojp.onmicrosoft.com
}

以上でGraphへのアクセス部分の作成は完了です。

4. Azure Blob Storage への出力

Blob ストレージへの出力は簡単です。コードを書く必要は一切ありません。

「統合」メニューをクリックしてください。

画面右上の「新しい出力」をクリックすると出力先一覧が表示されるので、「Azure BLOB ストレージ」を「選択」します。

「Blobパラメーター名」に「$Return」を指定します。これは、コードの最後に書かれた「 Return responseString; 」に関連しています。responseString 変数に格納された値が、Return されます。

「ストレージアカウント接続」にはストレージアカウントを指定してください。既存のものでも新規に作成することもできます。

パスはストレージアカウント内にファイルを保存するときのフルパスです。コンテナは事前に作成しておく必要はありません。指定したコンテナが自動的に作成されます。{rand-guid}は保存するたびにランダムなGUIDを生成することを意味しています。「.txt」を付けておくと開くときに便利です。

以上で作業は完了です。

放っておけば5分に1回、Graph API が呼び出されてBlobストレージにその時点のユーザー一覧のスナップショットがとられます（役に立つかどうかは不明ですが。。。）

一言でいえば、Azure Automation の”開発屋さん版”です（って、適当すぎて怒られそうw）。

Azure Automation は PowerShell スクリプトをクラウド上でジョブ化することができますが、Azure Functions は C#、F#、Node.js、Python、PHP Java などで書いたプログラムを WebJob として登録することができます。いずれも、サーバーを置くことなくジョブを実行することができる、いわゆるサーバーレスを実現するためのコンポーネントです。

PowerShell 好きの私的には Automation が好みではありますが、悔しいことに Functions のほうが高機能であることは否めません。何がいいって、入力や出力の定義が超簡単。これはAutomationにはない部分です。詳しくは以下の手順で。

Azure Functions の概要
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-overview

ためしに使ってみようかってことで、ここでは、Microsoft Graph にアクセスしてユーザー一覧を取得し、これを Azure Blob に保存するジョブを作成してみることにします。

Microsoft Graph にアクセスするので Azure AD 側の設定も必要になります、そこも含めて手順を書いておきますので参考にしてください。

1.  Azure Functions アカウントの作成

Azure Portal  の Marketplace で Function App を検索し、Function App をクリックしたら「作成」。

アプリ名等を入力して「作成」。アプリ名（ここでは GraphFromFunction.azurewebsites.net）は後でAzure AD にアプリ登録するときに使用します。

作成した Function App に移動すると、以下のようにApp Service（Functions の本体）、ストレージ、App Service プランが作成されていることがわかります。

App Service をクリックすると、Function App の簡易作成画面（クイックスタート）が表示されます。

今回は定期的に Microsoft Graph を実行するので「タイマー」を選択。言語は C#。

選択したら「この関数を作成する」をクリック。

初期画面が表示されたら、ためしに「実行」をクリックしてみる。

ログに以下のような出力がされれば、ひとまず正常です。太字部分はコード内の log.info() によって出力された文字列です。

2017-01-26T13:45:00.009 Function started (Id=db7524a6-c10b-4d9a-9e44-b61e86898aa0)
2017-01-26T13:45:00.009 C# Timer trigger function executed at: 1/26/2017 1:45:00 PM
2017-01-26T13:45:00.009 Function completed (Success, Id=db7524a6-c10b-4d9a-9e44-b61e86898aa0)

この関数はタイマーにバインドされているので、規定時間（5分）に1回、自動的に実行されます。

タイマーの間隔を変更するには、左側のメニューの「統合」をクリックします。

右下に「スケジュール」と書かれたフィールドがありますが、これが間隔を示しています。

設定の方法は以下を参照してください。

0 */5 * * * *

Azure Functions におけるタイマー トリガー
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-bindings-timer

2. Azure AD にアプリ登録する

Function App からいったん離れて、今度は Auzre AD 側の設定をします。実は、AppService の認証/承認の設定からでもできるのですが、今回は何が行われているのかを理解してもらうために面倒な手順で進めてみます。

なお、Azure AD について詳しく知りたい方は以下のリンクがおすすめです。

Azure AD ディレクトリの管理
https://github.com/Microsoft/azure-docs.ja-jp/blob/master/articles/active-directory/active-directory-administer.md

Azure AD は旧ポータルで操作するのがセオリーですが（ほんとかよ）、ここはあえて新ポータルでいってみましょう。

ポータルで「Azure Active Directory」を開いてください。

「プロパティ」をクリックすると「ディレクトリ ID」が表示されるので、これを控えておきます。あとから、ソースコード内で「Tenant ID」として使用します。

TenantID = c9687145-521f-42e6-xxxx-xxxxxxxxxxxx

次に「アプリの登録」をクリックすると、指定したテナントに関連づけられているアプリケーションの一覧が表示されます。

「追加」をクリックします。「アプリケーションの種類」は「Webアプリ/API」を選択。「サインオンURI」には、先ほど作成した Function App の URL(https://graphgromgunction.azurewebsites.net) を指定して「作成」をクリック。

先ほどのアプリ一覧に、今作成したアプリが追加されるので、クリックして設定画面を開きます。

「プロパティ」をクリックして表示された情報から「アプリケーション ID」を控えておきます。これはあとから「Client ID」としてソースコード内で使用します。

ClientID = e67fff1a-d912-4bf4-xxxx-xxxxxxxxxxxx

今度は「キー」をクリックします。

既定ではキーは作成されていません。

「機関」からキーの有効期限を選択し（ここでは「期限なし」）、「キーの説明」を適当に入力して「保存」をクリック。保存が完了すると「値」にキーが表示されるので、これを控えておきます。これがコード内で ClientSecret となります。キーが表示されたら、それを控えるまではページを移動しないでください。移動すると、安全のため二度と表示できなくなります。もしキーを忘れてしまったら、既存のものを消して新しくキーを作成すれば OK です。

ClientSecret = b/dmwx0WUnmljqxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

この作業で以下の3つの情報を収集することができました。

<Tenant ID> c9687145-521f-42e6-xxxx-xxxxxxxxxxxx

<Client ID> = e67fff1a-d912-4bf4-xxxx-xxxxxxxxxxxx

<Client Secret> = b/dmwx0WUnmljqxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

これらの値を、この後の作業で Function App 内に埋め込みます。

Azure AD の最後の作業として、アプリケーションにディレクトリへのアクセス権を与えます。

 アクセス権が無いと、正しいトークンを取得しても以下のようなエラーが発生します。

2017-01-27T04:29:02.895 {
  "error": {
    "code": "Authorization_RequestDenied",
    "message": "Insufficient privileges to complete the operation.",
       "innerError": { "request-id": "96e44229-5f66-4057-b9ea-f864b5013097",
       "date": "2017-01-27T04:29:01"
      }
    }
}

「必要なアクセス許可」をクリックしてください。既定では以下のようになっています。

アクセス権について詳しく解説はしませんが、このままではアクセスすることができません。

アクセス許可スコープ | Graph API 概念
https://msdn.microsoft.com/ja-jp/library/azure/ad/graph/howto/azure-ad-graph-api-permission-scopes

今回は、Function App がユーザーのログオンを介さずに直接 Graph API にアクセスします。そのため、アプリケーションに対して直接権限を与える必要があります。規定では「委任されたアクセス許可」なので、ユーザーがログオンしないとアクセスすることができないのです。

API 一覧にある「Windows Azure Active Directory」をクリックすると、以下のように権限一覧画面が表示されます。「アプリケーションのアクセス許可」の中にある「Read directory data」を選択してください。既定で与えられている「Sign in and read user profile」は必要ないので外してしまいましょう。アプリケーションには余計な権限を与えてはいけません。「保存」をクリックして保存しましょう。

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

3. Function App の作成

Function App の設定画面に戻ります。

既存のコードを以下で上書きして下さい。コード内の Tenant ID、Client ID、Client Secret に先ほど控えた値を埋め込みます。Client Secret を生のまま埋め込むのはアレなので、本当はApp Service のパラメタに登録するのがよいのですが、ひとまずここでは生埋め込みでいっちゃいましょう。パラメタ登録についてはあとで説明します。

#r "Newtonsoft.Json"

using System.Net;
using System.Net.Http.Headers;
using Newtonsoft.Json;
using Microsoft.IdentityModel.Clients.ActiveDirectory;

public static async Task<String> Run(TimerInfo myTimer, TraceWriter log)

{
    log.Info($"C# Timer trigger function executed at: {DateTime.Now}"); 
   
    string resourceId = "https://graph.microsoft.com";
    string tenantId = "<Tenant ID>";
    string authString = "https://login.microsoftonline.com/" + tenantId;
    string clientId = "<Client ID>";
    string clientSecret = "<Client Secret>";
    //string clientSecret = ConfigurationManager.AppSettings["clientSecret"];

    log.Verbose("ClientSecret=" + clientSecret);
    log.Verbose("authString=" + authString);

    var authenticationContext = new AuthenticationContext(authString, false);
   
    //アクセストークン取得;
    ClientCredential clientCred = new ClientCredential(clientId, clientSecret);
    AuthenticationResult authenticationResult = await authenticationContext.AcquireTokenAsync(resourceId,clientCred);
    string token = authenticationResult.AccessToken;
    log.Verbose("token=" + token);

    var responseString = String.Empty;
   
    using (var client = new HttpClient())
    {       
        string requestUrl = "https://graph.microsoft.com/v1.0/users";
       
        HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, requestUrl);
        request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token);
        log.Verbose(request.ToString());
       
        HttpResponseMessage response = client.SendAsync(request).Result;

        responseString = response.Content.ReadAsStringAsync().Result; 

        log.Verbose(responseString);
       
    }

    return responseString;

}

残念ながら、このままでは動作しません。

ちょっと説明が面倒なのですが、今回は Microsoft Graph にアクセスするため、必要なモジュールを追加しなければなりません。モジュールによっては、コードの先頭に以下のように書くことで、自動的に Nuget から追加されます。

#r "Newtonsoft.Json"

これに関する詳細が知りたい方は、以下の「外部アセンブリの参照」を参照してください。

Azure Functions C# developer reference (Azure Functions C# 開発者向けリファレンス)
https://docs.microsoft.com/ja-jp/azure/azure-functions/functions-reference-csharp

残念ながら Microsoft Graph に必要なモジュール（Microsoft.IdentityModel.Clients.ActiveDirectory）は #r では追加することができません。

そこで、特別なファイルを作成してアップロードしてあげる必要があります。以下の  JSON ファイルを作成して、Project.json というファイル名で保存してください。3.13.8 は現時点での安定最新バージョンです。

Active Directory Authentication Library 3.13.8
https://www.nuget.org/packages/Microsoft.IdentityModel.Clients.ActiveDirectory/

Project.json

{
  "frameworks": {
    "net46":{
      "dependencies": {
          "Microsoft.IdentityModel.Clients.ActiveDirectory": "3.13.8"
      }
    }
   }
}

ファイルを作成して保存したら、これを Function App にアップロードします。

画面右上の「ファイルの表示」をクリックしてください。

以下のように3つのファイルが存在していることがわかります。現在のコードは「run.csx」です。

「アップロード」をクリックして、先ほど作成した Project.json をアップロードしてください。

アップロードが完了すると、Nuget から必要なモジュールが自動的にダウンロードされて組み込まれます。

これで動くようになったはずです。

コード画面の「実行」ボタンをクリックしてみてください。

ログに、以下の赤枠で囲んだようなJSON形式のデータが出力されていれば成功です。 

今回は、Graph の URL を以下のようにユーザー一覧を取得するように設定したので、Azure AD に登録されているユーザー一覧が取得できています。

https://graph.microsoft.com/v1.0/users

出力結果を JSON エディタ等で見ていただくと、以下のようなデータがユーザーの数だけ出力されています。

{
    "id":"deb57951-92af-4bc4-xxxx-xxxxxxxxxxxx","businessPhones":["+81 9099999999"],
    "displayName":"admin",
    "givenName":"admin",
    "jobTitle":"\u30a8\u30d0\u30f3\u30b8\u30a7\u30ea\u30b9\u30c8",
    "mail":"admin@pharaojp.onmicrosoft.com",
    "mobilePhone":"+81 9017xxxxxx",
    "officeLocation":"???-???????",
    "preferredLanguage":"ja-JP",
    "surname":"user",
    "userPrincipalName":admin@pharaojp.onmicrosoft.com
}

以上でGraphへのアクセス部分の作成は完了です。

4. Azure Blob Storage への出力

Blob ストレージへの出力は簡単です。コードを書く必要は一切ありません。

「統合」メニューをクリックしてください。

画面右上の「新しい出力」をクリックすると出力先一覧が表示されるので、「Azure BLOB ストレージ」を「選択」します。

「Blobパラメーター名」に「$Return」を指定します。これは、コードの最後に書かれた「 Return responseString; 」に関連しています。responseString 変数に格納された値が、Return されます。

「ストレージアカウント接続」にはストレージアカウントを指定してください。既存のものでも新規に作成することもできます。

パスはストレージアカウント内にファイルを保存するときのフルパスです。コンテナは事前に作成しておく必要はありません。指定したコンテナが自動的に作成されます。{rand-guid}は保存するたびにランダムなGUIDを生成することを意味しています。「.txt」を付けておくと開くときに便利です。

以上で作業は完了です。

放っておけば5分に1回、Graph API が呼び出されてBlobストレージにその時点のユーザー一覧のスナップショットがとられます（役に立つかどうかは不明ですが。。。）

Azure 上の全てのリソースは Azure AD に登録されたユーザーやグループを使用してアクセス制御が行えます。この時に使用するアクセス制御の方法を RBAC（Role Based Access Control）と言います。

Azure ポータル（https://portal.azure.com/）で何らかのリソース（いかの場合は仮想マシン）を選択すると、必ずメニューの中に「アクセス制御（IAM）」が表示され、ここを起点としてRBACを設定することができます。

RBAC の概念を簡単に図にすると、以下のようになります。リソースに直接アクセス権を設定するのではなく、ROLE を介してアクセス権を得ることになります。ROLE には「アクション」が定義されており、これが Azure のリソースに対して行える権限を表しています。

ここでは「仮想マシン作成協力者」というロールのアクションを見てみましょう。以下が仮想マシン作成協力者に定義されているアクション（アクセス許可）の一覧です。

見ていただくとわかりますが、リソースプロバイダーに対してアクセス権が設定されていることがわかります。リソースプロバイダーについてはここでは解説しませんが、リソースの種類だと思ってください。Microsoft Compute は仮想マシンに関連したリソースを意味しています。ここには仮想マシンや仮想マシンノスケールセットなどが含まれています。Microsoft Network はネットワークに関連したリソースを意味しており、仮想ネットワーク、ネットワークインターフェースなどのリソースが含まれています。

Microsoft Computeをクリックして表示した画面が以下です。Virtual Machine に対してフルコントロールが与えられているのがなんとなくわかりますか？Availability Sets には「読み取り」「書き込み」「削除」の権限が与えられています。

さて、ここからがいよいよ PowerShell の出番です。これらを PowerShell から確認してみましょう。

まずは、以下の PowerShell コマンドレットで Azure AD にログオンします。

Add-AzureRMAccount

次に、以下のコマンドを実行してみてください。

Get-AzureRmRoleDefinition "Virtual Machine Contributor" | `
    Select Actions | foreach {echo $_.actions}

実行結果は以下の通りです。Microsoft.Compute（太字）と上の画面ショットを比べてみてください。一致していることがわかると思います。以下のアクションで「*」はワイルドカードです。Microsoft.Compute/virtualMachines/* であれば、Microsoft.Compute/virtualMachines/ 配下のアクションのすべてにアクセスが可能であることを意味しています。

Microsoft.Authorization/*/read
Microsoft.Compute/availabilitySets/*
Microsoft.Compute/locations/*
Microsoft.Compute/virtualMachines/*
Microsoft.Compute/virtualMachineScaleSets/*
Microsoft.Insights/alertRules/*
Microsoft.Network/applicationGateways/backendAddressPools/join/action
Microsoft.Network/loadBalancers/backendAddressPools/join/action
Microsoft.Network/loadBalancers/inboundNatPools/join/action
Microsoft.Network/loadBalancers/inboundNatRules/join/action
Microsoft.Network/loadBalancers/read
Microsoft.Network/locations/*
Microsoft.Network/networkInterfaces/*
Microsoft.Network/networkSecurityGroups/join/action
Microsoft.Network/networkSecurityGroups/read
Microsoft.Network/publicIPAddresses/join/action
Microsoft.Network/publicIPAddresses/read
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.RecoveryServices/locations/*
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/*/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/read
Microsoft.RecoveryServices/Vaults/backupFabrics/protectionContainers/protectedItems/write
Microsoft.RecoveryServices/Vaults/backupPolicies/read
Microsoft.RecoveryServices/Vaults/backupPolicies/write
Microsoft.RecoveryServices/Vaults/read
Microsoft.RecoveryServices/Vaults/usages/read
Microsoft.RecoveryServices/Vaults/write
Microsoft.ResourceHealth/availabilityStatuses/read
Microsoft.Resources/deployments/*
Microsoft.Resources/subscriptions/resourceGroups/read
Microsoft.Storage/storageAccounts/listKeys/action
Microsoft.Storage/storageAccounts/read
Microsoft.Support/*

既定で用意されている「組み込みロール」は以下のページを参照してください。「仮想マシン作成協力者」 も組み込みロールの1つです。

RBAC: 組み込みのロール

https://docs.microsoft.com/ja-jp/azure/active-directory/role-based-access-built-in-roles

では、例えば「仮想マシンを起動/停止するだけ」の権限を持ったロールを定義することはできるのでしょうか？

もちろんできます。

まずは「仮想マシンの起動、停止」アクションを調べるために、Azure 上で用意されている全アクションの一覧を出力してみましょう。以下のコマンドを使用すると、すべてのリソースのすべてのアクションをグリッドビューに一覧表示することができます。

Get-AzureRMProviderOperation * | Out-GridView

Microsoft.Compute に関するアクションだけに絞り込むときは以下のように入力します。

Get-AzureRMProviderOperation -OperationSearchString Microsoft.Compute/* | Out-GridView

出力された結果の中で、仮想マシンの起動と停止、再起動に関するアクションは以下の通りです。

Microsoft.Compute/VirtualMachines/start/action

Microsoft.Compute/VirtualMachines/powerOff/action

Microsoft.Compute/VirtualMachines/restart/action

あと、当然仮想マシンの一覧を読み込めないと意味がないので、以下も必要です。read には /action を付加する必要はありません。

Microsoft.Compute/VirtualMachines/read

これだけでは足りません。PowerOff するには、ディスクを接続解除（deallocate）する権限も必要です。

Microsoft.Compute/VirtualMachines/deallocate/action

それでは、これらのアクションだけを持つロールを定義してみましょう。

はじめに新しいロールの枠組み枠を作成します。新規に作成する際は、既存のロールをコピーして再利用します。これは現在の標準手順ですので、そういうもんだと思ってください。

まずは $Role 変数に「仮想マシンの共同作成者」ロールの中身をコピーします。

$role = Get-AzureRmRoleDefinition "Virtual Machine Contributor"

忘れないうちに、Role の識別子である Id を Null にしておきます。Id は新規ロールを作成する際に、新しく割り振られます。

$Role.Id = $Null

次にロールの名前と説明文を指定しましょう。日本語でも英語でも大丈夫です。

$Role.Name = "仮想マシンの起動と停止"

$Role.Description = "仮想マシンの起動と停止、再起動ができます"

今度は $role に定義されたアクションをクリアします。

$Role.Actions.Clear()

ここまでできたら、$Role だけ入力して現在の設定値を確認しましょう。

ここに必要なアクションを埋め込みます。

$role.Actions.Add("Microsoft.Compute/VirtualMachines/start/action")
$role.Actions.Add("Microsoft.Compute/VirtualMachines/stop/action")
$role.Actions.Add("Microsoft.Compute/VirtualMachines/restart/action")
$role.Actions.Add("Microsoft.Compute/VirtualMachines/read")
$role.Actions.Add("Microsoft.Compute/VirtualMachines/deallocate/action")

最後に、このロールを使用するサブスクリプションを定義します。

サブスクリプションを定義するにはサブスクリプションのIDが必要なので、まずは以下のコマンドで SubscriptionId を取得しましょう。

Get-AzureRmSubscription

SubsctionId が取得できたら、この値を使用して以下のコマンドを実行します。

$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/9cb9d877-xxxx-xxxx-xxxx-xxxxxxxxxxxx")

最後に $Role に格納された情報を使用して新しくロールを作成するコマンドを実行します。

New-AzureRmRoleDefinition -Role $role

これで新規カスタムロールの作成は完了です。

さっそく、このロールをリソースグループに割り当ててみましょう。リソースグループに割り当てると、その中のすべてのリソースにアクセス権が継承されます。

Azure Portal でリソースグループを選択し、IAM を選択します。

次に、「追加」をクリックしてください。

「役割の選択」をクリックすると、今作成した「仮想マシンの起動と停止」という役割が表示されているはずです。新規に作成したカスタムロールは、オレンジ色のしるしがついています。

「仮想マシンの起動と停止」を選択したら、次にこのロールに割り当てるユーザーを指定して保存すれば完了です。

Azure Portal に割り当てたユーザーでログオンしなおしてみてください。

Virtual Machine 画面を開くと、アクセス権を割り当てたリソースグループの仮想マシンだけが表示されます。

そして、特定のを開くと以下のようになるはずです。「開始」「再起動」「停止」の操作が許可されていることがわかります。管理者の場合、ここに「削除」が表示されるはずですが、このユーザーには表示されていません。

「接続」が表示されていますが、現在のRBACでは接続ボタンを無効化することはできないようです。接続を許可したくない場合には、グループポリシー等を使用して、仮想マシンの内部でアクセス制御してください。

今回、このユーザーにはリソースグループの参照権限を与えていません。そのため、リソースグループ画面を開くと、以下のようになります。リソースグループへの権限を与えないと、その配下に一切のリソースを新規に作成することができません。

また、試しに特定の Virtual Machine から「ネットワーク インターフェース」を選択して情報を参照しようとしても、以下のようにアクセスが拒否されます。

さて、秋から冬にかけては大きなイベントが 2 つ開催されます。

1 つ目は アトランタで開催される Ignite（イグナイト）2016。もともと春に開催予定でしたが、諸事情（ご想像通りです）により秋にずれ込みました。

そして、Ignite 2016 を受けて 11/1-2 にお台場で開催される Japan Tech Summit 2016 です。

国内でも、Tech Summit の準備であわただしくなってきました。

が、まずは Ignite でどのような発表があるのか見ておかなければいかん！キーノートは夜だけど真夜中ってほどじゃないし、せっかくなのでライブ中継しちゃおう～ ってことで、以下のオンラインイベントを開催します。

キーノートの内容をやさしく解説してくれるのは、以下の素敵な Geeks です。

左から、順にご紹介します。

• Drew Robbins
  日本マイクロソフト株式会社 デベロッパー エバンジェリズム統括本部 テクニカル エバンジェリズム マネージャー
• 井上 章
  日本マイクロソフト株式会社 デベロッパー エバンジェリズム統括本部 テクニカル エバンジェリスト
• 蔵本雄一
  日本マイクロソフト株式会社 マイクロソフトテクノロジーセンター セキュリティアーキテクト
• 小塚大介
  Microsoft Corporation Developer Experience and Evangelism  Technical Evangelist

そして、Geeks 達を技術的にサポートしてくださる Microsoft MVP の方々がこちらです。「比較的高級なお弁当をご提供します」とのオファーに二つ返事で引き受けていただきました。ほんとすんまそん。。。Drew-san may treat you to a gorgeous dinner later.

左からご紹介します。

• 宮川 麻里 さん
  MVP for Office Servers and Services であって、Active Directory や Windows Server にも強いオールマイティなエキスパートです。
• 安東 沙織 さん
  MVP for Microsoft Azure
  NTTデータ ビジネスソリューション事業本部 データセンタ&クラウドサービス事業部
  確かココって AWS にむちゃくちゃ強い部門だったはずですが、それでいて Azure にも強いというハイブリッドに鍛え上げられたエンジニアです。
• 奥田 理恵 さん
  MVP for Office Servers and Services
  株式会社イルミネート・ジャパン
  Office 365 の世界では知らない人はいない超有名トレーナーです。彼女の関西弁で味付けされた Office 365 開発セッションにハマる方多し。

そして、現地からは会場の雰囲気が伝わる写真を、高添さんや山本美穂さん、そして MVP の皆さんがが投稿してくれるはずです！

Twitter のハッシュタグは、以下の通り。

#MSIgnite

#mstechsummit16

みなさんのご視聴、お待ちしております！

あ、忘れてた。最後に。。。。。

中継をサポートしてくれるのは、decode での Channel 9 中継でも同じみ、以下の media  streaming guys です。

]]> https://docs.microsoft.com/archive/blogs/junichia/%E5%88%9D%E3%81%AE%E6%97%A5%E6%9C%AC%E8%AA%9E%E7%89%88-azure-active-directory-%E5%B0%82%E9%96%80%E6%9B%B8%EF%BD%9E%E8%84%B1%E3%82%AA%E3%83%B3%E3%83%97%E3%83%AC%E3%83%9F%E3%82%B9-%E3%82%AF%E3%83%A9 Wed, 08 Jun 2016 20:32:27 GMT https://blogs.technet.microsoft.com/junichia/?p=11255 Gartner 社から発表された Magic Quadrant（マジック クアドラント） によれば、Azure AD Premium が IDaaS（Identity and Access Management as a Service）部門で Leader 枠に位置づけられています。

Gartner からリリースされているレポート（無償で読めます）によれば、IAM 分野における IDaaS の採用率は 2020 年までに 40% に上るとみられており、今後ますますクラウド上での IAM に注目が集まりそうです。

Gartner による分析では、IAM を大きな 3 つの機能の集合体であるととらえており、これらの機能が B2B や B2C を問わずさまざまなシナリオで動作することが前提となっています。

• IGA（Identity and Governance Management）
  • 少なくとも顧客の持つIdentity ストアとの同期が行え、管理用のインターフェースが提供されていて IDaaS から顧客のディレクトリを管理できる
  • ユーザー自身でパスワードをリセット
  • Identityのライフサイクル管理機能
  • さまざまなシステムへの自動プロビジョニング
  • アクセスのリクエスト（セルフサービス含む）
  • ポリシーの適用により重要なシステムへのアクセスに対するガバナンス
• Access
  • 少なくとも、Web プロキシやフェデレーションを使用したアプリへの SSO
  • フェデレーションがサポートされていない場合には、事前に格納してあるパスワードを使用した SSO の代行
  • その他、各種認証プロトコルのサポート
• Identity log monitoring and reporting
  • 少なくともIGAやAccessに関する各種イベントのロギングと、顧客がログを自身で分析できること、レポーティング機能（誰がどのシステムにいつアクセスを許可されたのか？誰がどのシステムにいつアクセスしたのか？）

Azure AD Premium は、上記のいずれにおいてもカバレッジ率が高いと判断された証です。

最近では、Azure AD Identity Protection というリスクベース認証機能がサポートされ、ますます安全性と柔軟性の高い認証基盤の設計が可能になりました。

そんな Azure AD ですが、まだあまり深く知らないという方もいらっしゃるはずです。

そんな方向けに Azure AD の日本語版最新刊をご紹介します。

日経BP社から刊行されたばかりの「Azure Active Directory 完全解説」です。

※ Amazon にリンクされてます

Azure AD の各種機能や設定のためのオペレーションを説明したものではありません。それらについては、もう少しすると素晴らしい書籍が出てくるはずです。

こちらは、Azure AD を使いこなすためのアーキテクチャーについて詳しく解説されたものです。特にプロトコル面、IdP の設計面で深く理解したい方にはおすすめです。文字でびっしりの書籍です。

アーキテクチャを具体的に実装するためのコードも、Visual Studio の使い方とともに書かれています。

著者は Azure AD 開発チームの Vittorio で、それを MVP の Naohiro Fujie さんとともに監訳しました。

結構日本向けに手を入れています。

おすすめです！

Active Directory にゴミ箱機能が実装されたのは Windows Server 2008 R2 からでした。覚えてます？

実は、Azure Active Directory にもゴミ箱があります。

ちょっと以下の画面ショットをご覧ください。これは、Office 365 に用意されている「削除済みのユーザー」というメニューです。

Office 365 上で削除されたユーザーは、いったんここ（ゴミ箱）に移動されます。移動されたユーザーは、30日後に完全に削除されます。逆に言えば、30日未満であればもとのアクティブなユーザーとして復活することが可能です。

ここであることに気づきますよね。

そうです。Office 365 のユーザー管理簿は Azure Active Directory ですから、そもそも Azure Active Directory 自身にゴミ箱機能があるんじゃないか？

まさにその通りです。

現在の旧ポータルで提供されている Azure Active Directory の管理画面では、念ながらゴミ箱を参照することはできませんが、PowerShell を使用すれば確認することができます。

まずは、Connect-MSOLService コマンドレットで Azure AD のテナントにログオンしましょう。

次に、Get-MSOLUser  -RetuenDeletedUsers コマンドを入力してみてください。ごみ箱に入っているユーザーを確認することができます。

削除されているユーザーが、「いつ」削除されたかを確認するには SoftDeleteionTimestamp プロパティを参照します。

このユーザーは 30 日後に削除されるわけですが、それがいつなのか？を確認するには SoftDeleteionTimestamp に 30 日を加えれば明確になります。以下のようなスクリプトを実行してみましょう。

削除されたユーザーを復活させるには Restore-MSOLUser コマンドレットを使用します。

Office 365 から見ても、復活していることがわかります。

さて、Active Directory の場合はソフト削除とハード削除の間隔を調整することができました。Azure AD はどうなのでしょう？

残念ながら、現在は 30 日のソフト削除期間を変更することはできません。

オンプレミスの AD で間隔の調整が行える大きな理由は、削除したはずのオブジェクトが残り続けることによるデータベースの肥大化を回避するためです。Azure AD のフリー版を使用している場合、オブジェクト数の最大数は 50 万です。オブジェクト数を抑えるために削除しても、実際には 30 日後に削除されるのだとすると、削除されるまでの間に 50 万の上限が問題になる可能性があります。是非ともソフト削除からハード削除への移行間隔を調整できるようにしていただきたいものです。

数ある Azure の機能の中でも、私が一番好きなものです。Automation を使用すると、Windows PowerShell スクリプトを Azure 上で実行することができます。

Azure 上で実行すると何がうれしいかというと、スクリプトを実行する環境を用意しておく必要が無いのです。

普段あまり意識しませんが、スクリプトを実行するためにはいくつかの条件を満たす必要があります。

• スクリプトを実行するサーバー、またはクライアントが生きている
• スクリプトによって処理されるターゲットが生きている
• ネットワークが生きている
• スクリプト実行に必要なモジュールがインストールされている

など。

こうした面倒な環境をすべてクラウドに任せてしまえるのが Azure Automation です。

Azure Automation の概要は以下の動画でどうぞ。

で、Azure Automation には Webhook 機能も実装されています。Webhook とは何かといえば、WEB の API だと思ってください。

普通スクリプトを実行するには、以下のようにスクリプトファイルを PowerShell のコンソールから入力して実行します。

PS C:> ./hogehoge.ps1

Azure Automation だと、スクリプト（正確には Runbook：ランブック と言います）を選択して「実行ボタン」をクリックすれば実行できます。

Azure Automation 上の Runbook は、「スケジュール」機能を使用してスケジューリングすることもできます。その他、Windows Server の機能を使用してスクリプトをタスクマネージャーに登録しておいて、時間が来たり何らかのイベントが発生したら実行する、なんてこともできますよね。

で、注目していただきたいのは以下の Webhook  です。

登録した Runbook に Webhook を設定することができます。

以下の画面を見てください。Webhook をクリックすると以下のような画面が開き、画面右下にあるような URL が発行されます。

これが Webhook です。

この URL を、なんらかの方法で Post してあげると、ここで作成した Runbook が実行できるんです。超便利じゃないですか？

ただし注意も必要です。

URL は以下のような形式です。以下のURLの token= 以降が、Webhook を識別するトークンになっており、これが外部にばれるとエライことになります。

https://s1events.azure-automation.net/webhooks?token=ypOAJiNYTwT%2fPlenxHHedJGdyB7DPkdwdkAHP6wwSNM%3d

なぜエライことになるかというと、誰でも実行できてしまうからです。

上記 URL を Post するのに便利なのは、Chrome の Advanced REST Client です。Edge の拡張機能にも REST Client があるとよいのですが、まだ提供されていないようで。。。誰か作ってください。

以下のように、「POST」を選択して URL を入力したら Send すれば URL を POST することができます。その結果、Webhook に関連付けられた Runbook が実行できます。

ではここで、Webhook 発行までの簡単な手順を。

1. Azure Portal http://portal.azure.com/ の左側のメニューから「参照」をクリック
2. Azure Automation アカウントをクリック
   
3. 「追加」をクリックして Automation アカウントを新規に作成
   
4. 作成された Automation アカウントをクリック
   
5. Runbook をクリック
   
6. 「Runbook の追加」をクリック
   
7. 「新しい Runbook を作成します」をクリック
   
8. Runbook の名前を入力し、Runbookのタイプを選択。タイプはワークフローがお勧めではあるのですが、ひとまず Webhook には関係ないのでここでは普通の PowerShell を選択しました。最後に「作成」をクリックしてください。
   
9. 作成すると以下のように編集画面が表示されます。今回は簡単に、Get-Date で日付を取得する Runbook にしましょう。
   
   ちなみに、Ger-Date をローカルで実行すると以下のような出力結果が得られます。
   
10. 「保存」して「発行」します
    
11. 発行が完了したら「Webhool」をクリック
    
12. 「新しいWebhookの作成」をクリックして、Webhook の名前を指定します。有効期限は規定では1年が設定されています。必要最小限の期限にしましょう。
    ここで、必ずURLをコピーしておきます！これを忘れると、このURLは二度と取得することができません!!! ま、その場合は再作成すればよいだけの話なのですが。
    
13. URL をコピーしたら 「OK」
    
14. 最後に「作成」
    
    

以上で Webhook の作成完了です。

URL を Chrome の Advanced REST Client にペーストして実行してみましょう。

以下のように「Accepted」が戻されたら成功です。

Runbook の「ジョブ」をクリックして、実行結果を確認してみましょう。

ジョブはすでに完了しているようです。タイミングによっては、ジョブの実行準備中の場合もあります。

完了したジョブをクリックしてみると、以下のように正常に終了したことがわかります。

「出力」をクリックすれば、以下のようにGet-Date の結果として日付が出力されたことがわかります。

どうでしょう？結構面白そうな機能ですよね。

例えばある開発案件があって、開発者が Windows Azure 特有の機能の作りこみが苦手だったとしたら、Webhook の出番です。

あなたが PowerShell で Runbook を作り、Azure Automation に載せて Webhook を準備するだけです。開発者は、用意された Runbook をPostすれば、目的の処理の出来上がり！ってわけです。

で、つい最近 OMS から Webhook の呼び出しがサポートされました。

Introducing WebHook support for OMS Alerts
https://blogs.technet.microsoft.com/msoms/2016/03/30/introducing-webhook-support-for-oms-alerts/

OMS とは Operations Management Suite のことです。

OMS を使用すると、Azure や AWS などの IaaS 上の仮想マシン、さらにはオンプレミスの Hyper-V や VNWare 上の仮想マシンを監視することができます。簡易的な System Center 的な位置づけの製品で、今後どんどん機能が拡張されて System Center Operations Manager を凌駕する可能性もあります（現時点では全然追いついていませんけどね）。

上記の Blog でも紹介されていますが、OMS で Webhook がサポートされると「監視」と「アクション」を簡単に結び付けることができるようになります。

例えば、AWS 上の仮想マシン上で特定のイベントIDを持つエラーログが発生したら、Azure Automation に登録した PowerShell スクリプトを実行してリカバリーするとか。。。アイデアは無限大！

クラウドを介するので連携性もばっちりです。

ただ、Webhook の URL の管理だけはきちんと行ってください。

お勧めは Azure KeyVault です。

KeyVault が気になる方は、以下のPPTをご覧ください。

入社して2か月後、大胆にも System Center の発表イベントに登壇し、System Center Essentials という懐かしい製品を担当しました。

あまりの緊張に自己紹介を忘れ、セッション途中でふと思い出し「あ、こんにちは安納です」と東京ダイナマイト張りの自己紹介を行ったことは、いまでは懐かしい思い出です。ホールの後方で見ていた当時直属の上司 長坂さん、奥主さん、田辺さん（今はなぜか V 社に）がずっこけいてる様子がよく見え、「あー、こんな広い会場でも一番後ろの人の顔まで見えるのか」と感動したものです。

ちなみにこのイベントは、現在は会長の樋口さんの登壇デビューでもあり、そういう意味では樋口会長と私は同期であると言えなくもないです（こ、こえぇぇこと言ってる。。。。気がする。。。）。

はじめてのセミナーは、確か Active Directory でした。あの頃はまだ Windows Server 2003 R2 を使っていたはずです。このセミナーは、高添さん骨折によるピンチヒッターでした。まだ新宿のサザンタワーにオフィスがあった時代です。なつかしいですね。Zoomit の使い方に慣れておらず、注目してほしいところに丸をつけるつもりが塗りつぶしてしまうという Zoomit アルアルもよい思い出かと。

初めての出張も、確か高添さんとじゃなかったかな。この辺の記憶が定かではありませんが、場所は仙台でした。

私は前職の影響で「資料のようなスライド」を作る癖がありました。文字がビッチリ書いてあるような。”読めばわかる”資料です。

一方で、高添さんの資料はシンプルなんです。当時の超馬鹿な私から見れば、「え？それでいいんすか？オヤビン？」って感じです。

で、セミナーが始まり高添さんが話し始めて驚きました。

さっきまで「文字が無くてスカスカですけど？」なスライドに明確な意味が出てくるんですよ。スライドとスライドが物語のようにつながってくるんですよ！

なんですかこれ！？この感覚、高添さんのセッションに出たことがある方はわかると思うんですが、「この素材にはこの調味料！」的な組み合わせなんです。

「このスライドにはこの説明しかない！」。逆も真です。「この説明にはこのスライドしかない！」んです。スライドと説明が互いに欲しあっているという（いやらしい言い方だな）。高添さんは物語を語るようにテクノロジーを語ります。まるで一流の紙芝居（ってのがあるのかどうかわかりませんが）を見ているような感覚です。

それまで私はスライドで語ろうとしていました。言葉はスライドの補足だと思っていたんですね。だからビッチリと文字を書きこまざるを得なくなるんです。しかし高添さんは全く逆だったんです。伝えるのはスライドじゃなくて高添自身さんであり、主体はエバンジェリストである高添さん自身であると。聖書に語り部たるエバンジェリストがいるように、これこそが テクニカル エバンジェリストに求められている役割なのであると理解したのです。

今でも、忙しいとついついスライドを主体にしてしまいたくなるのです。何でもかんでも書き込むと楽なんですよねぇ～。読めるからww。でも、スライドを極限までシンプルにすると、ストーリーを組み立てて覚える必要があるので時間もかかるし大変なんです。でも、そのほうが聴き手には響くんです。間違いなく。

これを知れたのは、これから始まる私のエバンジェリスト人生にとって非常に大きな収穫でした。

ちょっと話が変わりますが、入社前は Windows Server Management という分野の MVP でした。今は亡き、柳原さんの推薦によるものです。

今だから言いますが、「オレ、ケッコウ、クワシイ、ナカナカ、イケテル、トミタヤスコ、スキ」と思っていましたヨ。

ほんと恥ずかしい（赤面）。

で、こんなオイラなら MS に入社しても十分やってけるだろう！とうかつに考えていたのですが、いざ入社してみると。。。。orz

そりゃー Windows の会社ですから、Windows に詳しい人間なんて捨てるほどいるわけですよ。

しかも、エバンジェリズムグループに入社したわけですから。ここはその道のプロ集団です。誤解を恐れずに言えば、ずーーーーーーーーーーーーーっと Windows とかを触っていられる部署なんです。

提案書とか、お金の計算とか、上司と一緒に3時間客先で謝り続けるとか、夜中にスイッチのセットアップをしたりとか（小塚さんはしてるなww）、そんな必要は基本的に無い部署だったんです。9年の間に会社の変化とともに状況は変わりましたけどね。そんな環境にいる人たちに、そもそも敵うはずないじゃないですか。

いままで「MVPさん！」とか言って持ち上げられてきましたけど、社員になった瞬間に誰も尊敬してくれなくなるしwww扱いは雑になるわで、もう。。。

入社1か月で、かなりへこみました。ありゃー、これは想定外だったなと。こんなんでやっていけるんかいなって。

しかも彼らは情報収集が早いんですよ。いや、「収集」じゃないな。

正確には「把握」かな。情報を正しく「把握」するスピードが速いんです。

極端な例ですが、こんなことがありました。

アメリカ本社の人事で、どこかの製品開発本部の VP が変わったとき、当時同僚だった奥主（おくぬし）さんが何と言ったかというと。

「あぁ、あのテクノロジーはVPが始めたプロジェクトだからディスコンに向かうな。次に来るのが○○だから、こういう風に変わるよ」

ええええええ？？？？？？？なにそれ～～？？？？？

意味わからない～ww で、結果、その通りになるんですwwww 怖いです。外資怖いです。

でも、そういうことなんですよね。情報を正しく「把握」しておかないと、市場に向けるメッセージがブレますし、早めの把握は間違いを犯さないための防御にもなりえます。

「田辺の壁」って言葉が私の中にあります。「田辺」とは、今は V 社の田辺さんのことです。

私の入社が決まったあと、人事にお願いして事前ミーティングを開いていただきました。入社前に部門の様子とか求められることを聞いておきたかったんです。

そのとき、これから部長になる長坂さん（現 Empathy Co., Ltd. 経営戦略室長）がふともらしたのは「一人まだ変態が来ていないけど、始めましょうか」。「変態？どんな？」と思ったところにやってきたのが田辺さん。いたって普通の人でした。見た目は。

でも、後にその真意がわかりました。田辺さんは RFC の策定状況とかを見ながら数年後のテクノロジーや実装を予測する人でした。今 Windows にこの機能が実装されているのはこの RFC によるもので、その追加仕様が委員会を通過するから将来はこういう方向に進んでいくよ～なんてことを平気で言える人でした。「あの部署に、以前どこどこ会社にいたカレがやって来たから、今後この製品はこういう風に強化されるはず」とか。

「これは確かに変態だ。でも素敵だ！この壁を登りたい！」そう思ったものです。いまだに壁は登りきれていませんorz

そんな変態な方々に囲まれつつ、エバンジェリストとして少しだけ成長し、部門編成も大きく変わり、上司がアメリカ人になり、なんとか 10 年目を迎えようとしているいま、会社自身も大きく変わろうとしています。

マイクロソフトの本社社長 Satya Nadera は以下の 3 つがマイクロソフトのミッションであると唱えています。

• Reinvent productivity and business processes
• Build the intelligent cloud platform
• Create more personal computing

上記それぞれに「Openness」というエッセンスを加えると、マイクロソフトの動きがより明確に見えてくると思います。マイクロソフトのテクノロジーをより広いプラットフォームで利用できるよう、そして逆に、オープンソースなテクノロジーもマイクロソフトのプラットフォーム上で違和感なく使用できるようにすること。それは Interop とか相互互換性などというレベルではありません。すべてのエンジニアがプラットフォームの壁を越えて、違和感なく創造性を発揮できる環境を整えようとしています。

日本でも、そうした環境をがっつり訴求できるチーム作りを続けています。これはかなりマジです。どれくらいマジなのかを図るには直近の人事を見るのがいいです。なぜならば人事はお金がかかるからです。お金をかけていれば、それは間違いなく本気の証です。マイクロソフトの場合は。

エバンジェリズムチームには、新たに 元V社で Azure エバの山本さん、DevOps エバの牛尾さん、元 Oracle で Java エバの寺田さん、漫画家で Xamarin エバの千代田まどかさんが加わりました。他にも XBox エバの鵜木さん、DirectX エバの千葉さんとかがいたりするんです。ちょっと向こうのテーブルでは太田寛さんがガジェットの店を広げてハンダ付けとかしてるんです。日本のエバンジェリズムチームも、そうした動きを支え推進できる組織編制になったと、心から思います。

現在、Build 2016 というイベントがアメリカで開催中です。1日目のKeynoteをご覧になられた方は少ないと思いますが、もしお時間があれば是非ご覧ください。

https://channel9.msdn.com/Events/Build/2016/KEY01

メインテーマは More Personal Computing で、素敵なニューテクノロジーが次々と紹介され、さぁ最後にどこに終着するのかと思ったら！

私、ニコ生本番中にちょっと涙ぐんじゃいましたww。そっか、そういうことなのかと。それが、我々が目指す More Personal Computing なのかと思うとすごく勇気が出てきました。テクノロジーをもてあそびたいわけではないのです。

そんな我々は、５月２４-２５日に東京のプリンスパークタワーで有償のイベントを開催します。

いま私たちが感じている「変革する IT」を皆さんとともに共有できたら幸いです。有償ですけど。なんとかして稟議を通してお越しください！

早期割引は 4月28日までです！お待ちしております。Build 2016 のような、素敵な Keynote を現在検討中です。

今年のマイクロソフトは面白いですよ～!!

最後になりましたが、せっかくのエイプリールフールなので嘘をかましときますね。

• Linux 上で SQL Server が動くようになります！
• Windows 10 では Bash が使えるようになります！
• .NET は .NET Core という名前で Linux と Mac 向けにオープンソース化されました！
• Xamarin はマイクロソフトに買収され、今後無償化し、全ての Visual Studio ユーザーが利用できます！
• Xamarin は Visual Studio Community でも使えます！ Xamarin Studio Community も無償です！
• Visual Studio では iPhone のエミュレーターが使えるようになります！
• Visual Studio では Android のエミュレーターが既に使えてます！

やばい。嘘がつけない。。。