Power Apps のキャンバス アプリ コネクタの概要

データは、Power Apps で構築されたものを含め、ほとんどのアプリの中核にあります。 データはデータ ソースに格納され、接続を作成することによってそのデータをアプリに取り込みます。 接続では、データソースとの通信にコネクタを使用します。 Power Apps には、SharePoint、SQL Server、Office 365、Salesforce、Twitter など、よく使われているサービスやオンプレミスのデータ ソースの多くに対応したコネクタが用意されています。 キャンバス アプリへのデータの追加を開始するには、Power Apps でのデータ接続の追加 を参照してください。

コネクタは、データまたはアクションテーブルを提供する場合があります。 テーブルのみ、またはアクションのみを提供するコネクタがあり、両方を提供するコネクタもあります。 また、コネクタは、標準コネクタのまたはカスタム コネクタのいずれかとなります。

テーブル

コネクタでテーブルが提供されている場合は、テーブル ソースを追加してから、管理するデータ ソース内でテーブルを選択します。 Power Apps は、アプリにテーブル データを取得し、データ ソース内のデータを更新します。 たとえば、レッスンという名前のテーブルが含まれるデータ ソースを追加してから、ギャラリーやフォームなどのコントロールの項目プロパティを数式バーの次の値に設定できます:

プレーン データ ソースの項目プロパティ

データを表示するコントロールの項目プロパティをカスタマイズすることにより、アプリが取得するデータを指定できます。 前の例に続けて、レッスン テーブル内のデータを並べ替えまたはフィルター処理できます。そのためには、検索関数および SortByColumn 関数の引数としてその名前を使用します。 この図では、項目プロパティが設定された式では、TextSearchBox1 内のテキストに基づいてデータの並べ替えおよびフィルター処理を行うように指定されています。

拡張されたデータ ソースの項目プロパティ

テーブルを使用して式をカスタマイズする方法の詳細については、次のトピックを参照してください:

Power Apps のデータ ソースについて
Excel データからアプリを生成する
アプリの一からの作成
Power Apps におけるテーブルとレコードについて

注意

Excel ワークブック内のデータに接続するには、OneDrive のようなクラウド ストレージ サービスでホストされる必要があります。 詳細については、Power Apps からのクラウド ストレージに接続する を参照してください。

操作​​

コネクタによってアクションが提供される場合でも、以前と同じようにデータ ソースを選択する必要があります。 ただし、次の手順としてテーブルを選択するのでなく、コントロールをアクションに手動で接続します。そのためには、データを表示するコントロールの項目プロパティを編集します。 項目プロパティを設定した計算式では、データを取得するアクションが指定されています。 たとえば、Yammer に接続してから、項目プロパティをデータ ソースの名前に設定した場合、アプリは任意のデータを取得しません。 コントロールにデータを設定するには、GetMessagesInGroup(5033622).messages のようなアクションを指定します。

アクション データ ソースの項目プロパティ

アクション コネクタ用のカスタム データ更新に対処する必要がある場合は、パッチ関数を含む計算式を構築します。 計算式では、アクションおよびアクションにバインドするフィールドを特定します。

カスタム更新の計算式をカスタマイズする方法の詳細については、次のトピックを参照してください:

Patch
Collect
更新プログラム

注意

Power Apps は動的スキーマでは機能しません。 動的スキーマというフレーズは、同じアクションが異なる列を持つ異なるテーブルを返す可能性を示しています。 テーブルの列が異なる可能性のある条件には、アクション入力パラメーター、アクションを実行しているユーザーまたはロール、ユーザーが作業しているグループなどがあります。 たとえば、SQL Server ストアド プロシージャは、異なる入力で実行すると、異なる列を返す場合があります。 動的スキーマを持つアクションの場合、コネクタのドキュメントは戻り値としてこの操作の出力は動的です。 と表示します。 一方、Power Automate は動的スキーマで動作し、シナリオの回避策を提供する場合があります。

このテーブルには最も一般的なコネクタに関する詳細情報へのリンクが含まれています。 コネクタのリスト全体については、すべてのコネクタ を参照してください。

         
Common Data Service Common Data Service   クラウド ストレージ クラウド ストレージ **
Dynamics AX Dynamics AX   Excel Excel
Microsoft Translator Microsoft Translator   Office 365 Outlook Office 365 Outlook
Office 365 Users Office 365 ユーザー   Oracle Oracle
Power BI Power BI   SharePoint SharePoint
SQL Server SQL Server   Twitter Twitter

**Azure Blob、Box、Dropbox、Google Drive、OneDrive および OneDrive for Business に適用されます

標準コネクタおよびカスタム コネクタ

Power Apps は、多くの一般的に使用されるデータ ソースに標準コネクタを提供します。 Power Apps に使用するデータ ソースの種類に対する標準コネクタがある場合は、そのコネクタを使用する必要があります。 自分で構築したサービスなど、別の種類のデータ ソースに接続する必要がある場合は、カスタム コネクタを登録して使用する を参照してください。

すべての標準コネクタ

標準コネクタには特別なライセンスは必要ありません。 詳細については、Power Apps プラン を参照してください。

Power Apps フォーラム で特定のコネクタについて質問できます。さらに Power Apps アイデア で追加すべきコネクタまたは他の改善事項を提案できます。

セキュリティおよび認証の種類

アプリを作成してデータ ソースへの接続を作成すると、コネクタの選択により、認証に異なる方法を使用できるようになる場合があります。 たとえば、SQL Server コネクタを使用すると、統合済み Azure AD、SQL Server 認証、および Windows 認証を使用できます。 認証の種類ごとに、関連するセキュリティのレベルが異なります。 アプリケーションを使用するユーザーと共有する情報および権利について理解することが重要です。 この記事の主な例は SQL Serverですが、原則はすべてのタイプの接続に適用されます。

統合済み Azure AD

これはセキュリティで保護されたタイプの接続です。 例えば、SharePoint ではこのタイプの認証を使用します。 SQL Server では、このタイプの認証も可能です。 接続すると、Azure AD サービスは、ユーザーの代わりに SharePoint に対してユーザーを個別に識別します。 ユーザー名やパスワードを入力する必要はありません。 作成者は、資格情報を使用してデータ ソースを作成および操作できます。 アプリケーションを公開し、アプリケーション ユーザーがログインする場合、資格情報を使用して実行します。 データがバックエンドで適切に保護されている場合、ユーザーは資格情報に基づいて、表示を許可されているもののみを表示できます。 このタイプのセキュリティでは、アプリケーションが公開された後に、バックエンド データ ソースで特定のアプリケーション ユーザーの権限を変更できます。 たとえば、バックエンド データ ソースでアクセス権の許可、拒否、またはユーザーまたは一連のユーザーが表示できるものすべてを調整できます。

オープンスタンダード認証 (OAuth)

このタイプの接続もセキュリティで保護されています。 例えば、Twitter ではこのタイプの認証を使用します。 接続するときは、ユーザー名とパスワードを入力する必要があります。 作成者は、資格情報を使用してデータ ソースを作成および操作できます。 アプリケーションを公開し、アプリケーション ユーザーがログインする場合、資格情報も入力する必要があります。 ユーザーはデータ ソース サービスにアクセスするために自分の認証情報を使用する必要があるため、このタイプの接続はセキュリティ保護されています。

SQL ユーザー名とパスワード認証

このタイプの接続は、エンドユーザー認証に依存しないため、あまり安全ではありません。 SQL Server では、このタイプの認証も可能です。 SQL Server では、このタイプの認証は SQL Server 認証と呼ばれます。 他の多くのデータベース データ ソースが同様の機能を提供します。 アプリケーションを公開するとき、ユーザーは一意のユーザー名とパスワードを入力する必要はありません。 アプリケーションを作成するときに入力したユーザー名とパスワードを使用しています。 データ ソースへの接続認証は、ユーザーと暗黙的に共有されます。 アプリケーションが一旦公開されると、接続も公開され、ユーザーが使用できるようになります。 エンド ユーザーは、共用されている SQL Server 認証による接続を使用してアプリケーションを作成することもできます。 ユーザーはユーザー名やパスワードを表示できませんが、接続は利用可能です。 このタイプの接続には、確実に有効なシナリオがあります。 たとえば、社内の全員が利用できる読み取り専用データベースがある場合、このタイプの接続は有効である可能性があります。

Windows 認証

このタイプの接続は、エンドユーザー認証に依存しないため、あまり安全ではありません。 オンプレミスであるデータ ソースに接続する必要がある場合は、Windows 認証を使用します。 このタイプの接続の例として、SQL Server を持つオンプレミス サーバーへの接続があります。 接続はゲートウェイを経由する必要があります。 ゲートウェイを経由するため、コネクタはそのデータ ソース上のすべてのデータにアクセスできます。 その結果、入力する Windows 資格情報を使用してアクセスできる任意の情報をコネクタで利用できます。 さらにアプリケーションが一旦公開されると、接続も公開され、ユーザーが使用できるようになります。 つまり、エンド ユーザーも同じ接続を使用してアプリケーションを作成し、そのコンピューターのデータにアクセスできます。 データ ソースへの接続も、アプリが共有されているユーザーと暗黙的に共有されます。 このタイプの接続は、データ ソースがオンプレミス サーバーにのみ存在し、そのソースのデータを自由に共有できる場合に有効です。