Power Platform で Teams データを取得してみた
こんにちは。システムソリューション営業本部の吾妻です。
先日この技術ブログで、「Teams データを取得してみた」というシリーズ記事が公開されました。
C#実装でTeamsのデータを取得する方法に関する記事で、執筆者は（私も以前所属していた）スクラッチでの開発を行うチームの大先輩です。
本記事では、同様にTeamsのデータを収集したい場合に、「Power Platformで実装したローコードアプリケーションで」実現するとしたらどのような方法があるのかを、ご紹介したいと思います。
Teamsのチャネル情報やメッセージに限らず、Graph APIを経由してデータを取得する際に応用できる手法なので、Outlookから予定の一覧を取得したり、SharePointからアイテムを取得したりといった、Graph APIで公開されている類似のエンドポイント（データ）にご関心のある方も、参考にしていただければと思います。
| Microsoft Japan Partner of the Yearについてはこちら➡ |
Teamsコネクタ
Power Platformには、Microsoft Teamsコネクタが用意されているので、これを利用することで難しいことを考えることなく、DataverseテーブルやSharePointリストにアクセスするのと同様に、テーブル形式でチームやチャネル、メッセージなどの一覧を取得することができます。
なので、単にTeamsデータを収集したいだけであれば、これ以降のGraph APIを呼び出す手順は特に必要ありません。次のスクリーンショットは、Teamsコネクタのみでデータを取得・表示するサンプルです。
事前準備
Power AutomateからGraph APIを呼び出す際にも、事前にAzure ADアプリを登録しておく必要があります。
まだ利用できるアプリがなければ、こちらの記事と同様にアプリを登録します。
ただし、APIのアクセス許可では、「委任されたアクセス許可」だけでなく、
「アプリケーションのアクセス許可」のアクセス許可も追加しておきます（後ほど、2種類の取得方法をそれぞれ試すため）。
アクセス許可の種類
アクセス許可の種類として、「委任されたアクセス許可」と「アプリケーションのアクセス許可」の2種類があります。
これらがどのように違うのかを、次の表に示します。エンドポイントによっては、どちらかのアクセス許可の種類でしかアクセスできないものもあるため、まずは呼び出したいエンドポイントのドキュメントを開いて、「アクセス許可」の項目を確認してみてください。
| アクセス許可の種類 | 委任されたアクセス許可 | アプリケーションのアクセス許可 | |
| 利用シーン |  ユーザーの権限で実行する際に利用 |
 バッチ処理で利用 （ユーザーがいない） |
|
| アプリが要求するアクセス許可に同意する人 | ユーザーまたは管理者 | 管理者のみ | |
| 保護されたAPI※1 | - | (Microsoftに申請しないと)利用できないエンドポイントがある | |
| Power Automateで使用するアクション | HTTP with Azure ADアクション※2 | HTTPアクションをいくつか (OAuthのフローに沿って1段階ずつ実装) |
HTTPアクション1つ |
※1 ... 保護された APIについてはこちらの記事に記載されています。「アプリケーションのアクセス許可」で取得しようとすると、「Invoked API requires Protected API access in application-only context when not using Resource Specific Consent.」といったエラーメッセージが返されます
クラウドフローの実装
パターン① 委任されたアクセス許可（HTTP with Azure ADアクションで実装）
「委任されたアクセス許可」でGraph APIへアクセスする場合、予めMicrosoft側で定義されたマルチテナントアプリケーションの「アプリケーションのアクセス許可※2」で充分であれば、HTTP with Azure ADアクションにGraph APIのURLを設定するだけで済みます。
Teamsのデータなどを取得するためのアクセス許可は含まれていませんが、ユーザーや予定表といった基本的なデータを取得するだけであれば、アクション1つだけ設定すれば済むので便利です。次のスクリーンショットは、「User.Read」のアクセス許可のみで利用できるエンドポイントに対してアクセスしてみたサンプルです。
※2 ... （Chat.ReadBasic, Chat.Read, Chat.ReadWrite'. Scopes on the request 'Application.ReadWrite.All, Calendars.ReadWrite, Calendars.ReadWrite.Shared, Contacts.ReadWrite, DelegatedPermissionGrant.ReadWrite.All, EduAdministration.Read, EduAdministration.ReadWrite, EduRoster.Read, EduRoster.ReadWrite, Files.ReadWrite.All, Group.ReadWrite.All, IdentityUserFlow.ReadWrite.All, Mail.ReadWrite, Mail.ReadWrite.Shared, Mail.Send, Mail.Send.Shared, MailboxSettings.ReadWrite, People.Read, People.Read.All, Sites.Read.All, Tasks.ReadWrite, User.Read, User.Read.All, User.ReadWrite）
パターン② 委任されたアクセス許可（HTTPアクションで実装）
HTTP with Azure ADアクションで対応していないエンドポイント（アクセス許可）を「委任されたアクセス許可」で利用したい場合には、HTTPアクションをOAuthの認証フローに従って複数組み合わせることで実装します。
次のスクリーンショットは、Teamsなどのプレゼンス（在席情報）を取得するためのエンドポイントに対して、「委任されたアクセス許可」を利用してアクセスしてみたサンプルです。
パターン③ アプリケーションのアクセス許可
「アプリケーションのアクセス許可」でGraph APIへアクセスする場合は、HTTPアクションの「認証」以降のパラメーターを設定することで実現できます。
次のスクリーンショットは、ユーザーが所属しているTeamsの「チーム」を取得するためのエンドポイントに対して、「アプリケーションのアクセス許可」を利用してアクセスしてみたサンプルです。
まとめ
今回は、Power PlatformでGraph APIからTeamsデータを取得する方法についてご紹介しました。Power Platformならではのコネクタを経由したデータ取得だけでなく、スクラッチ開発と同様のGraph APIを経由したデータ取得もできることは、Power Platformの拡張性に関する大きなメリットだと思います。
日常の業務を効率化したり、社内に散らばっている様々なデータの利活用を進めたりするためにも、本記事でご紹介したようなGraph APIへのアクセスや、カスタムコネクタを利用したAPIへのアクセスなど、コネクタ（や、そこに含まれるトリガー／アクション）が用意されていないデータも含めて、Power Platformと他サービスとの連携を進めると良いかと思います。
QESでは、お客様のご要件に応じて、ローコードツールによる開発と通常のプログラミング言語によるスクラッチ開発のどちらもご対応可能ですので、
どちらが適しているのかといったふんわりとしたご相談からでも、まずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
