Power BIでAPIデータを取り込む方法：Webコネクタと認証の基本

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から「最小で動く接続」を作ることです。

  1. Power BI Desktopで「データの取得」→「Web」を選ぶ

  2. URLを入力する

  3. 認証方法を選ぶ

  4. ナビゲーターまたはPower QueryエディターでJSONを展開する

  5. 「閉じて適用」でモデルに読み込む

ポイントは、いきなり複雑な加工をしないこと。まずは「取れる」ことを確認し、その後に整形します。

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のレスポンスは、だいたい次のどちらかです。

  • パターンA：配列が返る（例：[{…},{…}]）

  • パターンB：オブジェクトの中に配列がある（例：{ “data”:[{…}] }）

Power Queryでの考え方は単純で、配列は行、オブジェクトは列にしやすい、というイメージです。

UI操作の基本はこうです。

  • JSONが表示されたら「リスト」または「レコード」をクリックして中身を見る

  • 「テーブルに変換」を押す

  • レコード列ができたら「展開」ボタンで必要な項目を列にする

  • 型（数値、日付、テキスト）を整える

最初は全項目を展開し、後から不要列を削る方が迷いません。

6. Mで書くと安定する：Service更新まで見据えた基本形

初心者でも、最低限次の形だけは知っておくと後々楽です。
ポイントは「BaseUrlを固定し、RelativePathとQueryで可変部分を渡す」ことです。これを意識すると、Serviceで更新できない問題を避けやすくなります。

let
BaseUrl = "https://api.example.com/",
Token = Parameter_Token,Source =
Json.Document(
Web.Contents(
BaseUrl,
[
RelativePath = “v1/sales”,
Query = [
from = “2025-01-01”,
to = “2025-01-31”
],
Headers = [
Authorization = “Bearer ” & Token,
Accept = “application/json”
] ] )
),

Data = Source[data],
Tbl0 = Table.FromList(Data, Splitter.SplitByNothing(), null, null, ExtraValues.Error),
Tbl1 = Table.ExpandRecordColumn(Tbl0, “Column1”, {“date”,”store_id”,”amount”}, {“date”,”store_id”,”amount”}),
Typed = Table.TransformColumnTypes(Tbl1, {{“date”, type date}, {“store_id”, Int64.Type}, {“amount”, type number}})
in
Typed

上の例では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では、関数を作ってページを繰り返し取得し、最後に結合します。

let
BaseUrl = "https://api.example.com/",
Token = Parameter_Token,GetPage = (p as number) as list =>
let
Response =
Json.Document(
Web.Contents(
BaseUrl,
[
RelativePath = “v1/orders”,
Query = [
page = Text.From(p),
per_page = “100”
],
Headers = [
Authorization = “Bearer ” & Token,
Accept = “application/json”
] ] )
),
Items = Response[data] in
Items,

Pages =
List.Generate(
() => [p = 1, items = GetPage(1)],
each List.Count([items]) > 0,
each [p = [p] + 1, items = GetPage([p] + 1)],
each [items] ),

AllItems = List.Combine(Pages),
Tbl0 = Table.FromList(AllItems, Splitter.SplitByNothing(), null, null, ExtraValues.Error),
Tbl1 = Table.ExpandRecordColumn(Tbl0, “Column1”, {“id”,”created_at”,”total”}, {“id”,”created_at”,”total”}),
Typed = Table.TransformColumnTypes(Tbl1, {{“id”, type text}, {“created_at”, type datetime}, {“total”, type number}})
in
Typed

これで「最後のページが空になったら停止」できます。レート制限が厳しいAPIでは、ページ数が多いと更新が失敗することもあるので、次の工夫も覚えておくと安心です。

  • 1回の取得件数（per_pageやlimit）を上げる

  • 期間指定（from/to）で分割して取る

  • 更新頻度を下げるか、夜間に寄せる

9. POSTで取得するケース：ボディを送る基本

検索条件が複雑なAPIはPOSTを要求することがあります。Power Queryでは、ContentにJSONを渡し、ヘッダーでContent-Typeを指定します。文字列で頑張ってエスケープするより、Json.FromValueを使うと安全です。

let
BaseUrl = "https://api.example.com/",
Token = Parameter_Token,Body =
Json.FromValue(
[
from = “2025-01-01”,
to = “2025-01-31”,
status = {“paid”, “shipped”}
] ),

Source =
Json.Document(
Web.Contents(
BaseUrl,
[
RelativePath = “v1/search/orders”,
Headers = [
Authorization = “Bearer ” & Token,
#”Content-Type” = “application/json”,
Accept = “application/json”
],
Content = Body
] )
)
in
Source

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

  • トークンが間違っている、期限切れ、ヘッダー名が違う可能性

  • Bearerの後ろにスペースがあるかなど、細部も確認

403 Forbidden

  • 権限不足、IP制限、特定ユーザーのみ許可など

  • API側で許可されたスコープが足りない場合もある

404 Not Found

  • RelativePathやバージョンが違う

  • 末尾のスラッシュの有無で変わるAPIもある

429 Too Many Requests

  • 呼びすぎ。ページングで大量取得すると起きやすい

  • 取得範囲を絞る、更新頻度を下げる、夜間に寄せる

500系（サーバーエラー）

  • API側の不調。時間を置いて再実行で直ることもある

  • たまに起きる前提で、取得範囲を分割して影響を小さくする

Power Query側の赤いエラー（式のエラー、フィールドがない等）

  • JSONの形が想定と違う（dataがない、nullが混じるなど）

  • try … otherwise を使って、欠損時の処理を用意すると安定する

12. 実務のコツ：速く、壊れにくく作る

初心者が実務で成果を出すためのコツを、最後にまとめます。

  • まずは最小の取得（1エンドポイント、1ページ）で成功させる

  • 取得用クエリと整形用クエリを分ける（段階を分けると原因が追いやすい）

  • APIを行ごとに呼ばない（テーブルの各行でWeb.Contentsを呼ぶと遅くて失敗しやすい）

  • 期間指定できるAPIなら、from/toで分割して取得する

  • Service更新を見据えて、BaseUrl固定＋RelativePath＋Queryを基本形にする

  • 秘密情報は直書きしない（パラメーター化と資格情報管理を徹底）

power bi api 取得は、最初は難しく見えますが、型が分かると一気に楽になります。Webコネクタで取って、JSONを表にして、認証と更新の壁を超える。まずはこの基本形を作り、次にページングやPOST、更新運用へ広げていくのが、手戻りの少ない進め方です。

もし困り事があるなら、まずは無料相談を

「DAX 関数が多すぎてどれを使えばいいか分からない」「複雑なロジックを組みたいけれど、エラーが出て解決できない」「会社全体で DAX を学習したい」など、Power BI やデータ活用でお悩みの方はぜひお気軽にご相談ください。
もし困り事があるなら、まずは無料相談はこちら

コンサルサービスの詳細や成功事例なども合わせてご紹介いたします。
社内にデータ活用のノウハウや専門人材が十分いない場合でも、弊社が伴走しながら最短ルートで成果を出せるようサポートいたします。

セミナーで学ぶ！DAX 関数の実践スキル

📊 Power BIでより効率的なレポート作成を！

Power BIハンズオンセミナー初級編では、短時間でデータモデリングのノウハウを学び、ビジネスに活かせるレポート作成を実践形式で習得できます。

📈 Power BIスキルを次のレベルへ！

DAX 関数 × データモデル設計 で、複雑なデータ分析やレポート作成もスムーズに！
Power BIハンズオンセミナー中級編 なら、実践形式で学べるから即戦力に。
業務効率をアップし、社内での評価を高めるチャンス！

DAX を使いこなすことで、Power BI の真価を最大限に引き出し、より高度な分析をスムーズに進めることができます。実践的な知識を身につけて、組織のデータドリブンな文化をリードしましょう。

関連記事

この記事へのコメントはありません。

カテゴリー

アーカイブ

検索