Azure データ分析基盤の構築手順｜Data Factory と Power BI 連携

URLをコピーしました！

はじめに

Azure には Blob Storage、Data Factory、SQL Database、Power BI といったデータ関連サービスが揃っており、これらを組み合わせると、生の CSV データを取り込んでレポートとして可視化するまでの一連のデータ分析基盤を構築できます。一方で、初めて構築する際は「どのサービスをどの順番で、どう接続するのか」「ネットワークや認証はどう設定すれば ADF から SQL Database に書き込めるのか」でつまずきやすい領域です。

この記事でわかること

Azure を使ったデータ分析基盤の全体アーキテクチャ（Blob → ADF → SQL → Power BI）
Data Factory による Blob から SQL Database へのデータコピー手順（GUI 操作で完結）
ADF から SQL Database へ接続するためのネットワーク・認証設定のポイント
CSV のアップロードから Power BI 可視化までの一連の流れ

結論として、構築の要点は次の 2 点です。データの流れは「Blob Storage（入り口）→ Data Factory（ETL）→ SQL Database（格納先）→ Power BI（可視化）」の 4 層で整理できます。そして ADF から SQL Database への接続では、ネットワーク（公開アクセスの範囲）と認証（SQL 認証またはマネージド ID）の 2 つの設定が成否を分けます。

データ分析基盤の全体アーキテクチャ

今回構築するデータパイプラインは、Azure の主要なデータサービスを左から右へ接続する構成です。生の CSV データから視覚的なレポートまでを、1 本のデータの流れとして組み立てます。

構成するリソースとその役割は次の通りです。

Azure Blob Storage: 分析の元となる CSV ファイルの置き場（データレイクの入り口）
Azure Data Factory（ADF）: 抽出・変換・書き出しを担う ETL パイプライン。Blob からデータベースへのコピージョブを GUI で作成する。
Azure SQL Database: データの格納先（データウェアハウス: DWH）。分析ツールからのクエリに応答する。
Power BI: SQL Database に接続し、データをグラフや表として可視化する BI ツール

STEP

Azure Blob Storage の準備

データの保存先となる Azure Blob Storage を利用するには、まず大枠となるストレージアカウントを作成し、その中にデータを格納するコンテナーを作成します。

ストレージアカウントの作成

Azure Portal の検索窓で「ストレージアカウント」と検索し、「＋作成」をクリックします。以下の設定を入力して作成を進めます。

リソースグループ: Test-RG（新規作成）
ストレージアカウント名: blobdemodata01（世界中で一意である必要があります）
地域: Japan West（西日本）など任意のリージョン
パフォーマンス: Standard
冗長性: ローカル冗長ストレージ（LRS）。検証用のため最も安価な構成で差し支えありません。

入力後、「作成」をクリックしてデプロイを完了させます。

コンテナーの作成

デプロイ完了後に「リソースに移動」をクリックし、作成したストレージアカウントの管理画面を開きます。

左側のメニューから「データストレージ」＞「コンテナー」を選択します。
画面上の「＋コンテナー」をクリックします。
名前を raw（未加工データを格納する意味合い）として「作成」をクリックします。

これでデータの受け皿が用意できました。

サンプルデータ（CSV）のアップロード

続いて、作成した rawコンテナーに分析対象のサンプルデータ（CSV ファイル）をアップロードします。今回は卓球の試合データ（demodata.csv）を使用します。

rawコンテナーをクリックして開きます。
画面上部の「↑ アップロード」をクリックします。
表示されたパネルで PC 内の demodata.csv を選択します。
「アップロード」をクリックします。

一覧にファイル名・サイズ・最終更新日時が表示されれば、STEP 1 は完了です。

参考: demodata.csv

Rally,Server,Winner,ServeType,Outcome,Axis,SpinClass,Length,Course,Contact,Set,match_id,created_at,player,opponent
1,HANAKO,HANAKO,Reverse sidespin serve,Service ace,reverse-side,non-backspin,half-long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
2,HANAKO,HANAKO,Reverse sidespin serve,Service ace,reverse-side,non-backspin,half-long,forehand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
3,TARO,TARO,Vertical-spin serve,Receive error (self),vertical,non-backspin,long,forehand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
4,TARO,TARO,Vertical-spin serve,Third-ball point (opponent),vertical,non-backspin,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
5,HANAKO,TARO,Reverse sidespin serve,Rally lost,reverse-side,non-backspin,long,forehand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
6,HANAKO,HANAKO,Reverse sidespin serve,Rally won,reverse-side,non-backspin,long,forehand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
7,TARO,HANAKO,Vertical-spin serve,Rally won,vertical,backspin-type,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
8,TARO,TARO,Vertical-spin serve,Rally lost,vertical,backspin-type,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
9,HANAKO,HANAKO,Reverse sidespin serve,Service ace,reverse-side,non-backspin,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
10,HANAKO,HANAKO,Reverse sidespin serve,Third-ball point (self),reverse-side,non-backspin,half-long,backhand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
11,TARO,TARO,Vertical-spin serve,Third-ball point (opponent),vertical,backspin-type,long,backhand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
12,TARO,TARO,Vertical-spin serve,Receive error (self),vertical,non-backspin,long,forehand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
13,HANAKO,HANAKO,Reverse sidespin serve,Service ace,reverse-side,non-backspin,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
14,HANAKO,HANAKO,Vertical-spin serve,Rally won,vertical,non-backspin,long,forehand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
15,TARO,TARO,Vertical-spin serve,Rally lost,vertical,non-backspin,long,forehand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
16,TARO,TARO,Vertical-spin serve,Receive error (self),vertical,backspin-type,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
17,HANAKO,HANAKO,Reverse sidespin serve,Service ace,reverse-side,non-backspin,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
18,HANAKO,HANAKO,Reverse sidespin serve,Service ace,reverse-side,backspin-type,long,forehand,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
19,TARO,TARO,Vertical-spin serve,Receive error (self),vertical,backspin-type,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO
20,TARO,TARO,Vertical-spin serve,Rally lost,vertical,non-backspin,long,middle,,1,3d0f0836,2025-09-02T19:28:52+09:00,HANAKO,TARO

STEP

Azure SQL Database の構築とネットワーク設定

データレイク（Blob Storage）の準備ができたら、次はデータを格納する Azure SQL Database を作成します。あわせて、ADF からの書き込みを通すためのネットワーク設定を行います。

論理 SQL サーバーの作成

Azure では、SQL Database 本体を作成する前に、土台となる「論理 SQL サーバー」を用意します。データベース作成ウィザードの中で同時に作成できます。

Azure Portal の検索窓で「SQL データベース」と検索し、「＋作成」をクリックします。
「基本」タブで以下を入力します。

リソースグループ: Test-RG（STEP 1 と同じものを選択）
データベース名: sqldemo

「サーバー」項目の下にある「新規作成」をクリックし、サーバー作成パネルを開きます。

SQL 認証（管理者アカウント）の設定

サーバー作成パネルで設定する認証情報は、後ほど Data Factory からの書き込みや、Power BI・ローカル PC からの接続で使用します。控えておくことをおすすめします。

以下を入力して「OK」をクリックします。

サーバー名: sqlsrvdemodata01（世界中で一意である必要があります）
場所: Japan West（西日本）
認証方法: 「SQL 認証を使用する」を選択
サーバー管理者ログイン: sqladmin（任意のユーザー名）
パスワード: 大文字・小文字・数字・記号を含む複雑なものを設定

元の画面に戻り、「コンピューティングとストレージ」は検証用であれば Basic など安価なプランに変更し、「確認および作成」でデプロイを完了させます。

参考: Network access controls – Azure SQL Database（Microsoft Learn）
“the logical server denies all connections to ensure security.”
（論理サーバーはセキュリティ確保のため、既定ですべての接続を拒否します）
https://learn.microsoft.com/en-us/azure/azure-sql/database/network-access-controls-overview

ファイアウォール（パブリックネットワークアクセス）の設定

SQL Database は既定で外部からの接続を拒否します。ADF からの書き込みを通すには、ネットワーク設定を行います。事前に設定しておくと、後続の接続エラー（接続拒否）を防げます。

デプロイ完了後、「リソースに移動」で SQL Database（sqldemo）の管理画面を開きます。
左側のメニューから「セキュリティ」＞「ネットワーク」をクリックします。
「パブリックネットワークアクセス」タブで以下を設定します。

「選択されたネットワーク」にチェックを入れる。
下方の「例外」にある「Azure サービスおよびリソースにこのサーバーへのアクセスを許可する」をオンにする。

さらに「クライアントの IPv4 アドレスを追加する」をクリックします（自分の PC からクエリエディターや Power BI で接続するため）。
画面左上の「保存」をクリックします。

ファイアウォール規則の反映には最大 5 分程度かかる場合があります。

なお「Azure サービスおよびリソースにこのサーバーへのアクセスを許可する」は手軽な反面、許可範囲が広い設定です。この設定は内部的に 0.0.0.0 のルールを追加し、自社サブスクリプションに限らず Azure 全体からの接続を許可するため、本番環境では許可範囲を絞るか、マネージド ID やプライベートエンドポイントで代替する方法が推奨されます。より安全な接続方法は次のセクションで解説します。

ADF から SQL Database への安全な接続（マネージド ID）

STEP 2・STEP 4 では手軽な SQL 認証を使用します。ここでは、より安全な接続方法として、システム割り当てマネージド ID（Microsoft Entra 認証）による接続を解説します。本番運用やパスワード管理を避けたい場合に適した方法です。

マネージド ID 接続の利点

マネージド ID は、ADF などの Azure リソースに紐づく ID で、接続にパスワードを必要としません。リンクサービスへ接続文字列やパスワードを記載せずに済むため、認証情報の漏えいリスクを抑えられます。Microsoft の公式ドキュメントでも、ADF から Azure SQL Database への接続方式の 1 つとして案内されています。

参考: Copy and transform data in Azure SQL Database（Microsoft Learn）
“Copying data by using SQL authentication and Microsoft Entra Application token authentication with a service principal or managed identities for Azure resources.”
（SQL 認証に加え、サービスプリンシパルやマネージド ID を用いた Microsoft Entra トークン認証でのデータコピーに対応）
https://learn.microsoft.com/en-us/azure/data-factory/connector-azure-sql-database

設定手順

マネージド ID で接続するには、SQL Database 側に ADF の ID をユーザーとして登録し、必要なロールを付与します。手順は次の通りです。

SQL サーバーに Microsoft Entra 管理者を設定する。SQL Database（sqldemo）が属する論理サーバーの「セキュリティ」＞「Microsoft Entra ID」（または「Azure Active Directory」）から、管理者となる Entra ユーザーまたはグループを設定します。
Entra 管理者でクエリエディターにログインする。クエリエディターのログイン画面で「Microsoft Entra 認証」を選び、手順 1 で設定した管理者でログインします。
ADF のマネージド ID をデータベースユーザーとして登録する。以下の T-SQL を実行します。adf-demo-01 は STEP 4 で作成した Data Factory 名（マネージド ID 名）に置き換えてください。

-- ADF のマネージド ID をデータベースユーザーとして作成する
CREATE USER [adf-demo-01] FROM EXTERNAL PROVIDER;

-- 読み取り・書き込みロールを付与する（用途に応じて最小権限で）
ALTER ROLE db_datareader ADD MEMBER [adf-demo-01];
ALTER ROLE db_datawriter ADD MEMBER [adf-demo-01];

リンクサービスの認証方式を変更する。STEP 4 で作成した ls_sqldemodata のリンクサービスを編集し、認証の種類で「システム割り当てマネージド ID」を選択します。ユーザー名・パスワードの入力欄は不要になります。「接続のテスト」が成功すれば設定完了です。

権限は用途に応じて最小限に絞ることをおすすめします。今回のように ADF が書き込みのみを行う場合でも、確認用に読み取りを併せて付与しておくと検証がしやすくなります。

参考: Managed identity – Azure Data Factory（Microsoft Learn）
“use least‑privilege RBAC on downstream resources, and regularly audit role assignments.”
（接続先リソースでは最小権限の RBAC を用い、ロール割り当てを定期的に監査すること）
https://learn.microsoft.com/en-us/azure/data-factory/data-factory-service-identity

なお、マネージド ID は ADF と SQL Database が同一の Microsoft Entra テナントにある場合に利用できます。テナントが異なる場合は、サービスプリンシパルとアクセストークンによる接続が選択肢になります。

ネットワーク設定の制約とリスク

STEP 2 で有効化した「Azure サービスおよびリソースにこのサーバーへのアクセスを許可する」は、設定が手軽な反面、許可範囲が広い点に注意が必要です。導入を検討する際の判断材料として、制約とリスクを整理します。

「Azure サービスへのアクセス許可」が許可する範囲

この設定をオンにすると、内部的に開始・終了がいずれも 0.0.0.0 のファイアウォール規則が追加されます。これは「Azure 内部からの通信を許可する」という意味で、自社のサブスクリプションに限らず、Azure 上のあらゆるサブスクリプションのリソースからの接続を許可することになります。検証環境では許容できても、本番環境ではセキュリティ上のリスクとなる場合があります。

参考: Network Access Controls – Azure SQL Database（Microsoft Learn）
“enabling the setting is more permissive than what most customers want.”
（この設定の有効化は、多くの利用者が望む範囲よりも許可が広くなります）
https://learn.microsoft.com/en-us/azure/azure-sql/database/vnet-service-endpoint-rule-overview

より安全な代替手段

本番環境では、次のいずれかで許可範囲を絞る方法が推奨されます。

マネージド ID による接続: 前述の通り、認証情報を持たずに接続でき、認証面の安全性を高められる。
IP ファイアウォール規則: 接続元を特定の IP アドレスやレンジに限定する。
仮想ネットワーク規則: 特定の仮想ネットワーク（サブネット）からの通信のみを許可する。
プライベートエンドポイント（Private Link）: パブリックエンドポイントを使わず、仮想ネットワーク内のプライベート IP で接続する。

これらを組み合わせ、「Azure サービスへのアクセス許可」をオフにすると、許可範囲を必要最小限に保てます。プライベートエンドポイントによる閉域接続の詳細は、関連記事『Azure Private Endpoint の設定手順』も参考にしてください。

補足: serverless 利用時の挙動

検証コストを抑えるために SQL Database の serverless（自動一時停止あり）を選ぶ場合、データベースが一時停止している間に ADF のパイプラインを実行すると、自動再開を待たずに実行が失敗することがあります。スケジュール実行する際は、リトライ設定を追加するか、事前にデータベースを起動しておく運用が安全です。

STEP

SQL Database でのテーブル作成

空のデータベース（sqldemo）が用意できたら、CSV データを受け入れるテーブルを作成します。Azure Portal には、ブラウザー上から直接データベースを操作できる「クエリエディター」が用意されています。

クエリエディターへのログイン

リソース一覧から SQL Database（sqldemo）の管理画面を開きます。
左側メニューの「クエリエディター（プレビュー）」をクリックします。
表示されたログイン画面で、STEP 2 で設定した SQL 認証の情報を入力します。

認証の種類: 「SQL Server 認証」
ログイン: sqladmin
パスワード: STEP 2 で設定したもの

「OK」をクリックします。

ログイン時に「Client IP is not allowed…」のエラーが出る場合は、STEP 2 の「クライアントの IPv4 アドレスを追加する」が保存されていない可能性があります。ネットワーク設定を見直してください。

テーブル作成クエリの実行

ログイン後、エディター画面に以下の SQL 文を貼り付けます。今回の卓球データの列構成に合わせたテーブルを作成します。

CREATE TABLE TableTennisDemo (
    Rally INT,
    Server NVARCHAR(50),
    Winner NVARCHAR(50),
    ServeType NVARCHAR(100),
    Outcome NVARCHAR(100),
    Axis NVARCHAR(50),
    SpinClass NVARCHAR(50),
    Length NVARCHAR(50),
    Course NVARCHAR(50),
    Contact NVARCHAR(50) NULL,
    SetNumber INT,
    match_id NVARCHAR(50),
    created_at DATETIME2,
    player NVARCHAR(50),
    opponent NVARCHAR(50)
);

画面左上の「▶ 実行」をクリックし、下部のメッセージ欄に「クエリが正常に実行されました」と表示されれば成功です。これで TableTennisDemo という空のテーブルが用意できました。

STEP

Azure Data Factory でのパイプライン構築

データの出発地点（Blob）と到着地点（SQL Database）が揃いました。ここからは Azure Data Factory（ADF）で 2 つを繋ぐパイプラインを作成します。

Data Factory Studio へのアクセス

ADF の設定は、Azure Portal とは別の専用画面「Data Factory Studio」で行います。

Azure Portal の検索窓で「データファクトリ（Data factories）」と検索し、「＋作成」をクリックします。
リソースグループ（Test-RG）を選択し、任意の名前（例: adf-demo-01）と地域を指定して「確認および作成」でリソースを作成します。
デプロイ完了後に「リソースに移動」をクリックします。
画面中央の「スタジオの起動（Launch studio）」をクリックします。
新しいタブで Data Factory Studio が開きます。

Linked Service（リンクサービス）の作成

ADF に Blob Storage と SQL Database への接続情報を登録します。これを Linked Service と呼びます。画面左端の「管理（カバン型アイコン）」を選択し、「リンクサービス」＞「＋新規」から以下の 2 つを作成します。

Blob Storage 用のリンクサービス。

データストア: Azure Blob Storage
名前: ls_blobdemodata
ストレージアカウント名: STEP 1 で作成した blobdemodata01
「接続のテスト」が成功したら「作成」

SQL Database 用のリンクサービス。

データストア: Azure SQL Database
名前: ls_sqldemodata
サーバー名 / データベース名: STEP 2 で作成したもの
認証の種類: SQL 認証（ユーザー名 sqladmin と STEP 2 のパスワード）
「接続のテスト」が成功したら「作成」

ここでは手軽な SQL 認証を使用しますが、パスワードを持たずに接続できるマネージド ID 方式がより安全です。設定方法は前述の「ADF から SQL Database への安全な接続（マネージド ID）」を参照してください。

Copy Data アクティビティの設定とマッピング

接続情報が登録できたら、「A から B へデータをコピーする」指示（アクティビティ）を作成します。

左端の「作成（鉛筆型アイコン）」を選択します。
「パイプライン」の「＋」から新規パイプラインを作成します。
「アクティビティ」一覧の「移動と変換」から「データのコピー（Copy data）」をキャンバスにドラッグ＆ドロップします。

ソース（コピー元）の設定

下部の設定パネルで「ソース」タブを開き、「＋新規」をクリックします。
Azure Blob Storage ＞ CSV（区切りテキスト）を選択します。

リンクサービスに ls_blobdemodata を選び、ファイルパスで rawコンテナー内の demodata.csv を指定して「OK」をクリックします。

シンク（コピー先）の設定

「シンク」タブを開き、「＋新規」をクリックします。
Azure SQL Database を選択します。
リンクサービスに ls_sqldemodata を選び、テーブル名で dbo.TableTennisDemo を指定して「OK」をクリックします。

マッピングの調整

「マッピング」タブを開き、「スキーマのインポート」をクリックします。
基本的に同名の列が自動で紐づきます。名前が異なる列（例: CSV 側が Set、DB 側が SetNumber）がある場合は、プルダウンから正しい列名を手動で選択します。

デバッグ実行によるデータコピー

設定が完了したら、実際にデータを流し込みます。

キャンバス上部の「デバッグ」をクリックします。
下部の「出力」タブに実行状況が表示されます。
ステータスが「実行中」から「成功（Succeeded）」に変われば、Blob から SQL Database へのコピーは完了です。

STEP

データ格納の確認と Power BI での可視化

ADF のパイプラインが成功したら、データの到着確認と Power BI での可視化を行います。

SQL Database でのデータ格納確認

STEP 3 と同様にクエリエディターを開き、sqladmin とパスワードでログインします。以下の確認用クエリを貼り付けて実行します。

-- テーブルの先頭 10 件を表示して確認する
SELECT TOP 10 * FROM TableTennisDemo;

「結果」タブに CSV のデータが表形式で表示されれば、データコピーは確認できます。

Power BI Desktop から Azure SQL Database への接続

データが SQL Database に格納できたので、PC 上の Power BI Desktop から接続します。

Power BI Desktop を起動し、ホーム画面の「データの取得」をクリックします。
検索窓で「Azure」と検索し、「Azure SQL データベース」を選択して「接続」をクリックします。

接続情報を入力して「OK」をクリックします。

サーバー: sqlsrvdemodata01.database.windows.net
データベース: sqldemo

サーバー名：`sqlsrvdemodata01.database.windows.net`
DB 名: `sqldemo`

認証画面で左側のタブから「データベース」（環境によっては「SQL Server」）を選択し、以下を入力して「接続」をクリックします。

ユーザー名: sqladmin
パスワード: STEP 2 で設定したもの

ナビゲーター画面で TableTennisDemo のチェックボックスをオンにし、「読み込み」をクリックします。

サーバー名は、STEP 2 で作成したサーバー名に .database.windows.net を付けたものです。Azure Portal の SQL データベース概要画面からもコピーできます。

可視化の例

「データ」ペインに TableTennisDemo の項目が表示されたら準備完了です。フィールドをドラッグ＆ドロップしてレポートを作成します。

横棒グラフ: サーブの種類（ServeType）ごとの得点傾向を分析。
積み上げ棒グラフ: サーブのコース（Course）ごとの得点傾向を分析。

これで Blob から Power BI までのデータ分析基盤が一通り完成します。

検証用の概算コスト

Azure の従量課金リソースを使うため、検証を始める前に概算コストの目安を把握しておくと安心です。料金は変動するため、最新の正確な金額は公式の料金ページで確認することをおすすめします。

各リソースのコスト感は次の通りです。

Azure Blob Storage: 今回のような小容量の CSV であれば、ストレージ料金はごくわずかです。
Azure SQL Database: 課金の中心になりやすいリソースです。検証用途であれば、DTU モデルの Basic（最小構成で月額数 USD 規模）や、無料アカウントで使える無償枠が選択肢になります。本番用途では、Microsoft が新規デプロイで推奨する vCore モデル（General Purpose）が一般的です。
Azure Data Factory: パイプラインの実行回数やデータ移動量に応じた従量課金で、今回のような単発のコピーであれば少額に収まります。

参考: DTU-Based Purchasing Model – Azure SQL Database（Microsoft Learn）
“You can get a free database in Azure SQL Database at the Basic service tier with an Azure free account.”
（Azure 無料アカウントを使うと、Basic サービスレベルで SQL Database を無償で利用できます）
https://learn.microsoft.com/en-us/azure/azure-sql/database/service-tiers-dtu

認証方式と購入モデルの選び方は、用途に応じて次のように整理できます。

認証方式: 手軽さを優先するなら SQL 認証、安全性を優先するならマネージド ID。
購入モデル: 予測しやすい固定料金なら DTU、リソースを個別にスケールしたいなら vCore、利用が不定期なら serverless。

検証が終わったら、課金を止めるためにリソースグループ（Test-RG）ごと削除しておくと、想定外の課金を防げます。

まとめ

Azure のデータサービスを組み合わせると、生の CSV から可視化までを 1 本のパイプラインとして構築できます。構築の要点は、データの流れの整理と、ADF から SQL Database へ接続するためのネットワーク・認証設定にあります。以下に要点をまとめます。

データの流れは Blob・ADF・SQL・Power BI の 4 層で整理
最初の準備は論理 SQL サーバーと管理者アカウントの作成
ADF からの接続にはパブリックネットワークアクセスの設定が必要
既定の「Azure サービスへのアクセス許可」は許可範囲が広い設定
本番ではマネージド ID による接続がより安全な選択肢
検証用途なら Basic や無償枠でコストを抑えられる
データ格納の確認はクエリエディターの SELECT が手軽

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね！

URLをコピーしました！

この記事を書いた人

とも

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ（ネットワーク・サーバ・クラウド・セキュリティ）の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus（取得から20年以上）／ VCAP-DCA ／ Azure Solutions Architect Expert

▶ 運営者プロフィール（詳細）

2026年7月
月	火	水	木	金	土	日
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31