一般的な問題

並べ替えの保持

データを並べ替えた場合は、その並べ替え順序がすべてのダウンストリーム操作で保持されると見なされる可能性があります。

たとえば、各店舗の最大の売上が最初に表示されるように売上テーブルを並べ替えた場合は、[重複部分の削除] 操作の実行によって、各店舗の上位の売上のみが返されると期待される可能性があります。 また、実際に、この操作が機能するように見えることがあります。 しかし、この動作は保証されません。

各操作のスキップやデータ ソースへのオフロード (これによって固有の順序付け動作が行われる可能性があります) など、Power Query で特定の操作が最適化される方法のために、集計 (Table.Group など)、マージ (Table.NestedJoin など)、重複除去 (Table.Distinct など) を通して並べ替え順序が保持されることは保証されません。

これを回避する方法がいくつかあります。 2 つの推奨事項を紹介します。

  • ダウンストリーム操作を適用した 後に 並べ替えを実行します。 たとえば、行をグループ化する場合は、各グループ内の入れ子になったテーブルを並べ替えてから、それ以上の手順を適用します。 このアプローチを示すサンプルの M コードとして Table.Group(Sales_SalesPerson, {"TerritoryID"}, {{"SortedRows", each Table.Sort(_, {"SalesYTD", Order.Descending})}}) があります。
  • ダウンストリーム操作を適用する前に (Table.Buffer を使用して) データをバッファリングします。 場合によっては、この操作により、バッファリングされた並べ替え順序がダウンストリーム操作で保持されます。

データ型の推論

Power Query では、列のデータ型が誤って検出される場合があります。 これは、Power Query では、データの最初の 200 行のみを使用してデータ型を推測しているためです。 最初の 200 行のデータが 200 行より後のデータと何らかの点で異なっていると、最終的に Power Query によって間違った型が選択される可能性があります。 (間違った型によって常にエラーが生成されるわけではないことに注意してください。 結果として得られた値が単純に間違っているために、問題の検出が困難になる場合もあります。)

たとえば、最初の 200 行には整数 (すべて 0 など) が含まれているが、200 行より後には 10 進数が含まれている列があるとします。 この場合、Power Query では、その列のデータ型を整数 (Int64.Type) であると推測します。 この推論により、整数以外のすべての数値の小数部分が切り捨てられることになります。

または、最初の 200 行にはテキストの日付値が含まれ、200 行より後にはその他の種類のテキスト値が含まれている列があるとします。 この場合、Power Query では、その列のデータ型を日付であると推測します。 この推論により、日付以外のテキスト値が型変換エラーとして処理されることになります。

型の検出は最初の 200 行に対して機能しますが、データ プロファイリングはデータセット全体に対して実行できるため、データ プロファイリング機能を使用して、クエリ エディターで最初の N 行を超えた (型の検出またはその他の任意の数の理由による) エラーに関する早い兆候を得ることを検討できます。

リモート ホストによって強制的に閉じられた接続

各種の API に接続していると、次の警告が表示される場合があります。

Data source error: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host

このエラーが発生した場合、最も可能性が高いのはネットワークの問題です。 一般には、まず、接続しようとしているデータ ソースの所有者に確認します。 その所有者が接続を閉じていないと考えている場合は、そこまでの途中にある何か (プロキシ サーバー、中間のルーターまたはゲートウェイなど) が原因である可能性があります。

これが何らかのデータでのみ、または大きなデータ サイズでのみ再現されるかどうかにかかわらず、ルート上のどこかでネットワーク タイムアウトが発生している可能性があります。 大きなデータでのみ発生する場合、お客様は要求をより小さなチャンクに分割できるように、データ ソースの所有者にその API でページングがサポートされているかどうかを確認する必要があります。 それがうまくいかない場合は、API からデータを抽出するための (データ ソースのベスト プラクティスに従った) 代わりの方法に従う必要があります。

TLS RSA 暗号スイートは非推奨

2020 年 10 月 30 日より、Microsoft のサーバーでは次の暗号スイートが非推奨になります。

  • "TLS_RSA_WITH_AES_256_GCM_SHA384”
  • "TLS_RSA_WITH_AES_128_GCM_SHA256”
  • "TLS_RSA_WITH_AES_256_CBC_SHA256”
  • "TLS_RSA_WITH_AES_128_CBC_SHA256”

サポートされている暗号スイートの一覧を次に示します。

  • "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
  • "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
  • "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
  • "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"

暗号スイートは、メッセージを暗号化して、クライアントまたはサーバーとその他のサーバーの間のネットワーク接続をセキュリティで保護するために使用されます。 Microsoft では、現在のセキュリティ プロトコルに準拠するために上記の暗号スイートの一覧を削除しています。 2021 年 3 月 1 日より、お客様は Microsoft の標準の暗号スイートのみを使用できます。

これらは、接続先のサーバーが Power Query Online または Power BI から接続するためにサポートする必要のある暗号スイートです。

Power Query Desktop (Power BI、Excel) では、暗号スイートを制御しません。 Power Platform (Power Platform データフローなど) または Power BI サービスに接続しようとしている場合は、OS でこれらの暗号スイートのいずれかが有効になっている必要があります。 Windows バージョンをアップグレードするか、または Windows TLS レジストリを更新すると、これらの暗号化のいずれかがサーバー エンドポイントによって確実にサポートされるようにできます。

サーバーがセキュリティ プロトコルに準拠していることを確認するには、TLS 暗号化とスキャナー ツールを使用してテストを実行できます。 その 1 つの例として SSLLABS があります。

お客様は、2021 年 3 月 1 日の前にサーバーをアップグレードする必要があります。 TLS 暗号スイートの順序の構成の詳細については、「トランスポート層セキュリティ (TLS) を管理する」を参照してください。

証明書の失効

Power BI Desktop の今後予定されているバージョンでは、SSL チェーン内のいずれかの証明書に証明書の失効状態がない場合、デスクトップからの SSL 接続が失敗します。 これは、証明書が明示的に失効された場合は失効によってのみ接続エラーが発生していた現在の状態からの変更です。 その他の証明書の問題として、無効な署名や証明書の有効期限が含まれることがあります。

失効状態が削除される可能性のある構成 (企業のプロキシ サーバーの場合など) が存在するため、失効情報を含んでいない証明書を無視するための別のオプションを提供する予定です。 このオプションでは、特定の場合に失効情報が削除されるが、作業を続行するためにセキュリティを完全には低下させたくない状況が許可されます。

これは推奨されませんが、ユーザーは引き続き、失効確認を完全に無効にすることができます。

エラー: 評価が取り消されました

Power Query では、バックグラウンド分析が無効になっており、クエリの更新中にユーザーがクエリを切り替えるか、またはクエリ エディターを閉じた場合、"評価が取り消されました" というメッセージを返します。

エラー: キーがテーブルのどの行とも一致しませんでした

Power Query が キーがテーブルのどの行とも一致しませんでした というエラーを返す可能性のある原因はたくさんあります。 このエラーが発生すると、マッシュアップ エンジンでは、検索しているテーブル名を見つけることができません。 このエラーが発生する可能性のある原因には次のものがあります。

  • テーブル名が (たとえば、データ ソース自体で) 変更された。
  • テーブルへのアクセスに使用されるアカウントに、そのテーブルを読み取るための十分な特権がない。
  • 1 つのデータ ソースに対して複数の資格情報が存在する可能性がある。これは Power BI サービスではサポートされていません。 このエラーは、たとえば、データ ソースがクラウド データ ソースであり、データ ソースにアクセスするために複数のアカウントが異なる資格情報で同時に使用されている場合に発生する可能性があります。 データ ソースがオンプレミスにある場合は、オンプレミス データ ゲートウェイを使用する必要があります。

制限: Windows 認証を使用している場合のゲートウェイ マシンのドメイン参加の要件

オンプレミス ゲートウェイで Windows 認証を使用するには、そのゲートウェイ マシンがドメインに参加している必要があります。 これは、"ゲートウェイ経由の Windows 認証" で設定されているすべての接続に適用されます。 データ ソースへのアクセスに使用される Windows アカウントには、Windows ディレクトリ内の共有コンポーネントやゲートウェイのインストールへの読み取りアクセスが必要になることがあります。

制限事項: Power BI サービスでのクロス テナント OAuth2 更新はサポートされていません

OAuth2 を使用して Power BI サービスからデータ ソースに接続する場合は、データソースが Power BI サービスと同じテナントに存在している必要があります。 現在、OAuth2 を使用したマルチテナント接続のシナリオは、サポートされていません。

制限事項: カスタム AD FS認証エンドポイントは、サービスでPower BIされていません

カスタム 認証 (Active Directory フェデレーション サービス (AD FS)) AD FS認証エンドポイントを使用する機能は、サービスPower BIされていません。 ユーザーに次のエラーが発生する可能性があります: リソースによって報告されたトークン サービスが信頼されていない