迷走ITProですわな~

ITPro駆け出しによるブログ。ゆるくいきます

環境の変化

久しぶりの投稿

言い訳させてください(コラ)

  • 2回目の転職
  • 結婚
  • ・・・もうねーわ

はい、あんま大したことなかったですね、すいません。まぁ、ようは2回目の転職しました。

今の仕事

ざっくり転職の理由を言うと、もう何もかも自分でやりたくなったからですね。
受託のSIしかり、ITコンサルしかり、結局色んなシステム化ニーズがある会社の社内ITの方が圧倒的に色々できるだろうと。

ということで、急成長している(仕組み化が間に合っていない)医療×ITを中心にサービスを提供しているベンチャー企業のコーポレートITという立場で働かせて頂いています。
入社して半年経過しましたが、今までやったことをざっくりリストアップすると

  • エンタープライズWikiシステム(Confluence)をIaaS(AWS)を使って社内展開(インフラレイヤ、アプリケーションレイヤ共設計・構築)
  • オフィス移転に伴い、最大500人規模の社内LAN設計・構築(床下配線からRouter Config, 無線AP設定まで)
  • G Suite のメールフロー整備(社内利用ポリシー策定・現行運用からの移行)
  • コーポレート機能周辺の業務プロセス改善提案・実行(Slack、GAS, AWS周りで)
  • PCキッティングの自動化(Powershell)
  • その他、通常の問い合わせ対応とか、トラブル対応とか

てな感じで、SIerやらコンサルやらやってた時に社外から一杯感じてたモヤモヤを完全に忘れさせてくれるぐらいやりたい事・やれる事まみれです。
上記の内容も出せる限りはここにガンガン出していきたいと思います。(実行する方向に注力しすぎて書けてませんでしたが)

今後やりたいこと

JDLAのG検定取ってから、しばらくAI, ML周りのネタから離れていましたが、「AIの民主化」の波もありハードルも下がってますし、色々使えそうなところが社内にもあるので何か一つは取り組みたいと思っています。

SharePoint REST サービスによる Microsoft Flow の拡張と SPD 連携

SharePoint Online(SPO)にて、ちょっと複雑なワークフローを作る際に色々得るものがあったので備忘録を兼ねて。

SharePoint クライアントサイドAPIについて

SharePoint のクライアントサイドAPIの使い分けについては、この辺りを読めば良い感じですね。

んで、今回利用する REST API はこれ。

SharePoint におけるワークフローについて

SharePoint は長らく SharePoint Designer(SPD) でワークフローを作成するというのが主流でしたが、SPD の開発停止発表、Microsoft Flow の機能強化、さらには Microsoft 内外とのサービス連携が活性化してきた昨今、SPD でのワークフロー作成もそろそろ不要になる流れです。
まだ Microsoft Flow 側のアクションが心もとない感じではありますが、下記の記事にもあるように SharePoint REST サービス呼び出しで機能補間が可能です。

ということで、「もう SPD いらねーな」と思っていた矢先・・・( ^ω^)

※処理対象のリストに参照列が13個以上含まれていると、REST APIがこけて詰みます。

ということでメインテーマ

SPD - Microsoft Flow 連携による Lookup 閾値の回避(イベント編)

結論から言うと、SPDでイベントハンドルして必要な情報だけ Microsoft Flow 側に Http Callで渡すことで回避できました。
※今回はイベント時のエラーでしたが、Flowによる操作対象がLookup閾値を超えている場合、別の工夫が必要かと思われます。
詳しい方法は、以下が参考になるかと。

Microsoft Flow での実装のほうが、デバッグやエラーハンドリングも捗るので、できるだけ Flow に寄せていきたいですね。

  • SPD 側の実装イメージ

f:id:michaelowen628:20180424173755p:plain

MS系 Chatbot 触ってみた

久しぶりに

世間のAI(というか機械学習)ブームに乗っかって、統計学やらの基礎理論から復習してると中々ここに書くネタもなくおろそかになってしまいました。
Azure MLやらAzure ML Workbenchやらも触ったんですが、やっぱり競馬とか株とかに繋げないと遊んでても面白くないですね。
その辺はまた今度競馬で遊ぼうかと思いますが、今回はChatbotネタを。

Botって

広義には、以下のような意味ですね。(Wikipedia抜粋)

Bot(ボット)は、robot(ロボット)の短縮形・略称。転じて、コンピュータやインターネットの分野においては、作業を自動化するプログラムの総称。

最近、「Bot」と使うと自動的に「Chatbot」に変換されて、さらにいうとなんかAIと紐づいてどんな質問しても色々返してくれるみたいなことを想像される人が多いですが、AI使わないBotも普通にあります。
というか、AIの定義も非常に曖昧なので、何をしたらAIなのかも微妙なところですね。
という前置きはこの辺にして本題になりますが、Microsoftから現在提供されている Chatbot 関連のサービスを以下の資料にまとめてみました。

※最近、ブログにまとめるというよりスライドにまとめて話すことが多く・・・あんまり見るだけだと分かんないです(;'∀')

私個人としては、Chatbotをスマート化しまくってカスタマイズを進めると、普通のWeb Applicationでいいじゃんってなる気がしていて、 この資料の中にあるQnA Maker + Azure Bot Serviceぐらいの感覚がChatbotを実装する上で一番バランスいいかなって思ってます。

Chatbotが実際に活用されている有名な例もはっつけておきます。(NTT Docomoが提供しているRepl-AIがベースになっているようですが)

横浜市のゴミ分別

まぁ、とりあえずはFAQ Chatbotが無難なところですかね。

JICS 2017 振り返り

予め記載させて頂くと、この記事はあまり技術的な話ではないです。

これですね。参加してきました。
※仕事の都合でAM中のセッションは聞けず

nosurrender.jp

AD FSを入り口として「Digital Identity」領域にハマって1年半ぐらい経ちますがこの領域の動向は非常に興味深いです。 改めての部分もありますが、面白かった内容を掻いつまんで記載していきたいと思います。

1. SNS IDを活用したB2C向けのID基盤

元々エンタープライズ領域ではMicrosoftのADが非常に高いシェアを誇っていましたが、クラウド・モバイル活用により社員のIDの在り方を改めて考え直す必要が出てきています。 また大学などの教育機関でも多くの場合、所属する学生に対してなんらかのIDを払い出してサービスを提供している形態になってきています。
しかし、普段の生活においてエンドユーザーはそれらのIDを必要としません。FacebookやLINE、インターネットショッピングに組織から払い出されたIDは使えません
利便性だけを考えるとFacebookやLINEに登録しているID(個人ID)と組織のIDを完全に同一のものにするのが理想的ですが、現在の状況を考えるとまだまだ難しいです。(プライバシー面(個人側)や、セキュリティ面(組織側)で)
そこで、一歩引いて組織から払い出されるIDと個人が利用しているIDを紐づけることで利便性を向上させる動きが出てきています。(Azure AD B2C + LINE ID等)
組織間コラボレーションを目的としたAzure AD B2Bというサービスもあるように、IDはもはや一つの組織の中で閉じるものでは無くなってきています。
将来的には個人IDで、自分に必要なすべてのサービスを利用できる日が来るかもしれませんね。

2. トラストフレームワークの基本と今後の適用分野

この業界でトラストフレームワークと聞くと真っ先に思いつくのがPKIでしょうか。これも基本的には考え方が同じです。
IdPとRP/SPが乱立する中、それぞれのID Federation確立時にIdPやSP/RPをセキュリティ面等でアセスメントするのは非常に非効率です。
そこでそれらのIdPやSP/RPが信頼に足るかを第3者機関によるトラストを付与しようという働きかけですね。
既に欧米では始まっている動き(TFPAP等)ですが、日本ではまだ大学のネットワークで発足しているGakuNinぐらいようです。
学術認証フェデレーション 学認 GakuNin
政府としてもトラストリポジトリの重要性を認知させるため、試作段階ものがあるようです。(XMLベースで作成されており、システムからの読み取りも容易な形式)
https://trustlist.openlabs.go.jp/
これらの目的はあくまでも組織間ID Federationの活性化なので、これ自体が営利目的に運営されるのは避けてもらいたいですが、仕組みとしては経済の活性化に繋がる取り組みかと思います。

3. 基礎から OAuth と OpenID Connect

OAuthとOIDCのプロトコルの詳細セッションなので内容は下記参照。
デジタルID最新動向(1):「OAuth 2.0」の基本動作を知る (1/4) - @IT

以前から広く言われていることですが、OAuthは認可のプロトコルであり、認証に使うのはセキュリティ上危険であることを改めて強調されていました。

4. Achieve Balance between Security, Usability and Privacy with Invisible Identity

企業側はセキュリティを中心にID基盤を構想しますが、過度なセキュリティのために利便性を欠いた環境になっているとエンドユーザーはそれを回避したがります。
例えば・・・

  • 多数のID・パスワードの設定 → 全て同一にする(個人で利用するサービスと同一Passを利用)
  • パスワードの定期的な変更の強制 → 覚えられないからメモに書いておく

など、これらは企業が過度なセキュリティを押し付けた結果、セキュリティホールが生まれていることになります。
結果として、セキュリティは強まるどころか弱まっている(目的と真逆の結果になっている)ことを認識すべきだと思います。
ユーザーエクスペリエンスの向上に関しても、ディズニーで利用されているバンドを例に挙げて解説されていました。
もしTDRに導入されたら “開園ダッシュ” がなくなる!?「ディズニー・ワールド」MyMagic+ 完全ガイド(1/5) - ディズニー特集 -ウレぴあ総研

5. Be Self Sovereign! Block Chain+Identityが目指す姿

Identityを自分で管理できない世界は非常に危険なのではないか。(Yourdentity
近年ID Federationの普及により、個人IDの世界でも利便性は向上しきていますが結局のところIdPに自分のIdentityを握られているのが現状です。(FacebookGoogle等)
仮にFacebookGoogleアカウントが停止してその復旧が困難な場合、SAML、OAuthやOIDCで繋いでいる全てのIdP、SP/RPも利用ができなくなります。(組織IDの場合、望ましい状態かと思いますが)
個人IDの最終コントロール権は手元に残さないと、IdPの一存で個人のIDが停止されてしまうことを認識しましょう。
そして、それを解決する光となるのがBlock Chainによる分散台帳技術かもしれません。(Mydentity

今後のDigital Identity領域が楽しみです。

SharePoint Onlineにおける通知機能の補完方法

SharePointの通知にはリボンメニューから設定できる「個人用通知」と、SharePoint Designerで設定する「ワークフローのメール送信」がありますが、いずれも実際に使ってみると少し機能が足りないと感じることが多いです。
※個人用通知では、全く足りないですが・・・

私が過去に不足感を感じた用途は以下になります。

  • ワークフローを起動するタイミングが「アイテムが作成されたとき」or「アイテムが変更されたとき」しか設定できない f:id:michaelowen628:20170816205008p:plain
  • 匿名ユーザーの投稿や編集では、ワークフローの起動に失敗する

この問題に対応するために別途タスクスケジューラに対して条件に合うアイテムを「更新」するスクリプトを登録することで、SharePoint Designerで設定したワークフローを起動するようにして実現していることも多いかと思います。

オンプレミスのSharePoint Serverであればそれでいいのですが、上記の方法ではSharePoint Onlineに対応することができないです。
そこでSharePoint Onlineにおいて、上記問題を解決する方法を2点ご紹介させて頂きます。

  1. Office 365 サイト用の Azure Web ジョブ ("タイマー ジョブ") の使用の開始 | MSDN f:id:michaelowen628:20170816212652p:plain

  2. オンデマンド Flow による新しい SharePoint 通知 – MS Japan Office 365 Tech Blog f:id:michaelowen628:20170816212948p:plain

それぞれのソリューションを簡単に比較すると以下のようになります。

【価格】

  • Azure Webジョブ + SharePoint Designer
    Azure WebジョブはAzure App Serviceのコストがかかってきます。 ただ、他で利用しているAzure Web Appにのせることも可能です。

  • Microsoft Flow
    制限はありますが、多くのOffice 365ライセンスにプランが含まれています。
    プラン | Microsoft Flow

【機能】

  • Azure Webジョブ + SharePoint Designer
    SharePoint Online内で完結するのであれば、基本的にやりたいことはできます。
    Exchangeや、Skype、Dynamics等他のMicrosoft アプリと連携すると不利。
    ※Azure Webジョブ側にアップロードするスクリプトにコードを記載すれば多くのことを実現できるが、基本的にはSPDのトリガー補助を想定

  • Microsoft Flow
    SharePoint Online内で完結する場合、SPDのワークフローと比較して複雑なフローになりがちですが、機能面ではSPDにほとんど追いついていると考えられます。
    他のOffice 365アプリ等と連携する場合、とても強力です。

【運用】

  • Azure Webジョブ + SharePoint Designer
    SharePointリストと連携する等、実装を工夫することで、事前に想定される運用作業は軽減可能です。
    しかし根本的な実装面で改修が必要な場合、SPDスクリプトの理解及びその環境が必要になります。
    Powershell+CSOM等のスクリプトをオンプレミスで利用している場合、参照するDLLと合わせてアップロードすることでSharePoint Onlineでも同じスクリプトを利用可能です。

  • Microsoft Flow
    フローが複雑になりがちですが、ブラウザのみで比較的容易に編集可能です。   Json,zip形式でインポート/エクスポート可能ですが、当然ながらオンプレと異なる実装となります。

将来的にMicrosoftは、SharePoint DesignerとInfopathの開発を打ち切るとアナウンスしていることからも、Microsoft Flowの利用にも慣れておきたいところですね。

なお、今回はよく直面する問題として通知機能を中心に記載していますが、このソリューションはSharePoint Onlineに対してあらゆるスケジューリングタスクを実現してくれますので、応用範囲は多岐に渡ります。
是非色々試してみてください。

Azure上でNested Virtualizationが利用可能に

最近色々ゴタゴタしていたので久しぶりの投稿になります。

タイトルの通り、Azure上のVMNested Virtualizationが利用可能になったようですね。
(※一部のサイズに限定されているようですが)

azure.microsoft.com

オンプレでは、Windows Server 2016から既にこのNested Virtualization機能は利用できるようになっているので、Azureの仮想化基盤が追いついてきた形になります。
ちなみにオンプレの場合は、Hyper-Vホスト側で以下のコマンド実行が必要だったのですが、Azureではどうなるのでしょうか・・・

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

まぁ何はともあれ、これでAzure上でHyper-V周りの検証も実施できるようになりました。Docker for Windowsも内部的にはHyper-Vの機能を利用することになるので、今まではAzure上のVMで利用することができなかった仮想化周りの検証が捗りますね。

docs.docker.com

SharePoint Server 2013 利用状況ログについて

ちょっとSharePointネタで最近ハマったものを投稿します。

SharePoint Server 2010から移行する場合等は特に注意していただきたいのですが、SharePoint 2013から利用状況分析機能が大きく変化しています。
SharePoint 2010でアクセス解析等を行う場合、Web Analytics Serviceを使っていたと思いますが、こちら2013以降廃止されています。
SharePoint 2010 から SharePoint 2013 への変更点

で、2013以降代わりに利用状況レポートがあるのですが、これが少し曲者です。 検索クエリの分析等は問題なくできるのですが、利用状況のレポートをダウンロードしても数値がカウントされていない・・・?
f:id:michaelowen628:20170513150923p:plain

色々調べていると、どうやらStandard Editionでこのレポートは使えない!?との情報有り。
公式ブログ見てもUsage Reporting and LoggingUsage AnalyticsYesになってるけど大丈夫か(笑)
SharePoint 2013 onpremise edition comparison chart – SharePoint & Cloud

で、さらに色々調べているうちに以下のようなブログも発見。
SharePoint 2013 – Usage Analytics (the story) – SharePoint Support Blog PowerShell Script to Workaround No Data in SharePoint 2013 Usage Reports | The Frog Pond of Technology

ブログに記載の下記コマンドを実施してReceiverを追加してみたところ、確かにアクセス数が記録されるようになりました。
※コマンドの英語の部分を一部日本語に変更する必要がありました。

$ad = Get-SPUsageDefinition | where {$_.Name -like”分析の利用状況”}
$ad.Receivers.Add(“Microsoft.Office.Server.Search.Applications, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”,”Microsoft.Office.Server.Search.Analytics.Internal.AnalyticsCustomRequestUsageReceiver”) 
$ad.EnableReceivers = $true

$pd = Get-SPUsageDefinition | where {$_.Name -like”ページの要求”}
$pd.Receivers.Add(“Microsoft.Office.Server.Search.Applications, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c”, “Microsoft.Office.Server.Search.Analytics.Internal.ViewRequestUsageReceiver”)
$pd.EnableReceivers = $true 

ただMSのサポートにも問い合わせたところ、やはりこの機能はStandard CALでは使えないものとなっているようで、上記ブログの手順で有効化した場合は未サポートとなる旨の回答を頂きました。
ご利用に際してはご注意下さい。