APIからデータを取ってPower BIで可視化したい、という相談はとても多いです。基幹システムに直接つなげない、スプレッドシート運用が限界、外部サービスのデータをまとめたい。そうした場面で、power bi api 取得の基本を押さえると、最短で「更新できるレポート」に到達できます。
ただし、API連携は最初につまずきやすいポイントもあります。認証が通らない、JSONが展開できない、ページングで途中までしか取れない、Power BI Serviceで更新が失敗する。この記事では、初心者でも再現できるように、Webコネクタの使い方と認証の考え方、そして実務で頻出のパターンを順番にまとめます。難しい用語は必要最小限にして、手順と判断基準を中心に説明します。
1. 取り込みの全体像をつかむ
Power BIでAPIデータを取り込む流れは、ざっくり次の4段階です。
-
APIにリクエストしてレスポンス(多くはJSON)を受け取る
-
JSONを表(テーブル)に変換する
-
必要な形に整形する(列の展開、型変換、不要列削除など)
-
更新できる形にして公開する(DesktopとServiceの差を吸収)
このうち、初心者が最初に意識すべきは「APIにどうアクセスするか」と「Power BI Serviceで更新できるか」です。Desktopで表示できても、Serviceで更新できない作り方をしてしまうと手戻りが大きいからです。
2. 事前に確認しておくと失敗が減る情報
取り込みを始める前に、最低限次を確認しておくと、作業が早くなります。
-
エンドポイントURL(例:/v1/orders など)
-
取得方法(GETかPOSTか)
-
認証方式(APIキー、Basic、Bearerトークン、Azure ADなど)
-
返ってくる形式(JSONが多い。配列なのか、data配下なのか)
-
ページングの有無(page、offset、nextリンクなど)
-
レート制限(短時間に呼びすぎると止められることがある)
-
更新頻度(毎日なのか、毎時なのか)
ここが曖昧だと、Power BI側で頑張っても安定しません。仕様書がない場合は、まず「1回叩いた結果のサンプルJSON」を手に入れるのが近道です。
3. Power BI DesktopでWebコネクタを使う最短手順
初心者が最初にやるべきは、UIから「最小で動く接続」を作ることです。
-
Power BI Desktopで「データの取得」→「Web」を選ぶ
-
URLを入力する
-
認証方法を選ぶ
-
ナビゲーターまたはPower QueryエディターでJSONを展開する
-
「閉じて適用」でモデルに読み込む
ポイントは、いきなり複雑な加工をしないこと。まずは「取れる」ことを確認し、その後に整形します。
4. 認証の基本:よくある4パターンを押さえる
APIが開けない理由の多くは認証です。Power BIのWeb接続で出やすい認証は次の4つです。
4-1. Anonymous(匿名)
認証不要の公開APIなど。最も簡単です。
4-2. Basic(IDとパスワード)
ユーザー名とパスワードをHTTPヘッダーに載せる方式です。社内APIや古い仕組みで使われることがあります。
4-3. APIキー(キーを渡す)
Power BIでは「Web API」という認証方法として表示されることがあります。APIキーを入力してアクセスします。
ただし、APIによっては「ヘッダーにX-API-Keyで渡す」「クエリ文字列にapikey=で渡す」など流儀が違うので、合わない場合は後述のMでヘッダー指定します。
4-4. Bearerトークン(Authorization: Bearer …)
最近多い方式です。ヘッダーにトークンを入れます。トークンは短時間で期限切れになることもあるため、運用方法が重要です。
Azure ADで保護されたAPIなら「組織アカウント」でサインインして取得できる場合があります。一方、外部サービスの独自OAuthで都度ログインが必要なタイプは、標準のWebコネクタだけでは自動更新が難しく、別の仕組み(カスタムコネクタや中継)を検討することがあります。
初心者は、まず自分のAPIがどれに当たるかを確定させましょう。ここが決まると半分終わります。
5. JSONを表にする:最初に見るべき形は2つだけ
APIのレスポンスは、だいたい次のどちらかです。
Power Queryでの考え方は単純で、配列は行、オブジェクトは列にしやすい、というイメージです。
UI操作の基本はこうです。
最初は全項目を展開し、後から不要列を削る方が迷いません。
6. Mで書くと安定する:Service更新まで見据えた基本形
初心者でも、最低限次の形だけは知っておくと後々楽です。
ポイントは「BaseUrlを固定し、RelativePathとQueryで可変部分を渡す」ことです。これを意識すると、Serviceで更新できない問題を避けやすくなります。
上の例ではTokenをParameter_Tokenにしています。Power Queryの「パラメーターの管理」で作っておくと、pbixを他人に渡すときも整理しやすいです。
なお、JSONの形が違えば Source[data] の部分も変わります。レスポンスが配列そのものなら Source がリストになるので、data配下を参照せず、そのまま Table.FromList へ進めます。
7. 認証情報をどこに置くか:初心者がやりがちな失敗
やってはいけないのは、トークンやキーをMコードに直書きすることです。理由は3つあります。
-
共有したpbixに秘密情報が残りやすい
-
メールやチャット転送で漏えいリスクになる
-
後から変更するときに探しにくい
現実的な選択肢は次です。
-
Power Queryのパラメーターにして入力し、Desktopのデータソース設定で資格情報を管理する
-
Power BI Service側でも資格情報を設定し直して更新する
-
トークンが頻繁に変わる場合は、更新時に自動で取得できる仕組みを別途用意する(これは少し上級)
まずはパラメーター化と資格情報の設定で十分です。安定運用が必要になったら次を考えればOKです。
8. ページング対応:途中までしか取れないを防ぐ
APIは1回のレスポンスに上限があることが多く、ページングが必須になります。代表的な方式は次の3つです。
-
pageとper_page(またはlimit)
-
offsetとlimit
-
nextのURLがレスポンスに入る
初心者に扱いやすいのはpage方式です。Power Queryでは、関数を作ってページを繰り返し取得し、最後に結合します。
これで「最後のページが空になったら停止」できます。レート制限が厳しいAPIでは、ページ数が多いと更新が失敗することもあるので、次の工夫も覚えておくと安心です。
9. POSTで取得するケース:ボディを送る基本
検索条件が複雑なAPIはPOSTを要求することがあります。Power Queryでは、ContentにJSONを渡し、ヘッダーでContent-Typeを指定します。文字列で頑張ってエスケープするより、Json.FromValueを使うと安全です。
POSTが通らないときは、ボディの形式やContent-Typeの指定漏れが原因になりがちです。
10. Power BI Serviceで更新するための注意点
Desktopで成功しても、Serviceで「更新に失敗しました」となるのはよくあります。初心者が先に押さえるべきポイントは次の通りです。
10-1. 資格情報はService側でも設定する
公開後、データセットの設定画面で、データソースの資格情報を入れ直す必要があります。Desktopの設定は自動で移らないことがあるためです。
10-2. 動的なURLを作りすぎない
MコードでURLを文字列結合してしまうと、Serviceが「どこに接続するのか分からない」と判断して更新できないことがあります。
対策は、BaseUrlを固定し、RelativePathとQueryで変化させることです。
避けたい例(文字列結合でURLを作る)
おすすめ(BaseUrl固定+RelativePath+Query)
-
BaseUrlは固定
-
RelativePathに”v1/orders”
-
Queryにpageとper_page
10-3. オンプレ環境や社内ネットワークはゲートウェイが必要
社内APIや社内ネットワーク内のURLにアクセスする場合、Power BI Serviceから直接は届きません。オンプレミスデータゲートウェイの設置が必要になります。
10-4. プライバシーレベルとファイアウォールで止まることがある
複数のデータソースを組み合わせたり、参照クエリが増えたりすると、式の保護(いわゆるファイアウォール)でエラーになることがあります。初心者の段階では、まず「取得専用のクエリ」と「整形用のクエリ」を分け、データソースが増えない構成にしておくと回避しやすいです。
11. よくあるエラーと対処の考え方
最後に、実務で頻出のエラーを「原因の見当がつく」形で整理します。
401 Unauthorized
403 Forbidden
-
権限不足、IP制限、特定ユーザーのみ許可など
-
API側で許可されたスコープが足りない場合もある
404 Not Found
-
RelativePathやバージョンが違う
-
末尾のスラッシュの有無で変わるAPIもある
429 Too Many Requests
-
呼びすぎ。ページングで大量取得すると起きやすい
-
取得範囲を絞る、更新頻度を下げる、夜間に寄せる
500系(サーバーエラー)
Power Query側の赤いエラー(式のエラー、フィールドがない等)
12. 実務のコツ:速く、壊れにくく作る
初心者が実務で成果を出すためのコツを、最後にまとめます。
-
まずは最小の取得(1エンドポイント、1ページ)で成功させる
-
取得用クエリと整形用クエリを分ける(段階を分けると原因が追いやすい)
-
APIを行ごとに呼ばない(テーブルの各行でWeb.Contentsを呼ぶと遅くて失敗しやすい)
-
期間指定できるAPIなら、from/toで分割して取得する
-
Service更新を見据えて、BaseUrl固定+RelativePath+Queryを基本形にする
-
秘密情報は直書きしない(パラメーター化と資格情報管理を徹底)
power bi api 取得は、最初は難しく見えますが、型が分かると一気に楽になります。Webコネクタで取って、JSONを表にして、認証と更新の壁を超える。まずはこの基本形を作り、次にページングやPOST、更新運用へ広げていくのが、手戻りの少ない進め方です。
コメント