Azure は VM だけじゃないー業務で“軽く使う” Azure の選択肢ー

Azure というと、「仮想マシン（VM）を立てて使うもの」というイメージを持たれることが少なくありません。
もちろん、Azure VM は今でも重要な選択肢です。ただ、業務のすべてをVMで構成しようとすると、
最初から重い構成になってしまう ケースも多く見てきました。

実際には、Azure には

• ちょっとした処理だけを任せる
• 必要な分だけデータを置く
• 運用をなるべくシンプルに保つ

ためのサービスが数多く用意されています。

この記事では、
VMを前提にしない「軽く使う Azure」という考え方を軸に、
業務で使いやすい Azure の主要コンポーネントと、その役割分担を整理します。

Power Platform と組み合わせたときの立ち位置や、
構成ができた後に考えるべき運用・保護の観点にも触れながら、
「まずはこのくらいから」で始められる Azure の使い方をまとめていきます。

目次

Azure ＝ VM (仮想マシン)と思われがちな理由

Azure というと、「仮想マシン（VM）を立てて使うもの」というイメージを持たれることが少なくありません。
実際、 Azure が企業向けに広く使われ始めた当初は、オンプレミスのサーバーをそのままクラウドに置き換える文脈で VM が多く利用されてきました。

また、 Windows Server や既存の業務システムとの親和性が高いこともあり、
「 Azure ＝ VM 」という印象が今も強く残っているのは自然な流れでもあります。

ただし、VM はあくまで Azure が提供する数多くの選択肢の一つにすぎません。
VM を使う場合は、OS の管理、パッチ適用、監視、バックアップなど、
オンプレミスに近い運用が引き続き必要になります。
そのため、業務の内容や規模に対して VM を前提に考えてしまうと、

• 最初から構成が重くなる
• 運用・管理の負担が大きくなる
• 「とりあえず全部 VM に乗せる」設計になりがち

といった状況に陥ることも珍しくありません。

Azure には VM 以外にも、
運用をできるだけ意識せずに使えるマネージドサービス が数多く用意されています。
VM ありきで考えることが、必ずしも最適解とは限らない──
ここが、 Azure を使う上で最初に整理しておきたいポイントです。

まず考えたい「軽く使う Azure 」という発想

業務で Azure を活用する際、最初から「高度な構成」や「将来を見据えた完璧な設計」を目指す必要はありません。
むしろ多くの現場では、

• いま困っている業務をどう支えるか
• 既存の流れをどう無理なく拡張するか

といった、現実的な課題 から Azure の導入が始まります。

そこで一つの考え方として持っておきたいのが、
「軽く使う Azure」 という発想です。
ここでいう「軽い」とは、

• 小規模・従量課金で始められる
• マネージドで運用負荷が低い
• 必要になったら後から広げられる

といった意味合いです。

Azure は IaaS（VM）だけではなく、
PaaS やサーバーレスといった形で
「使いたい部分だけを切り出して使う」ことができます。

重要なのは、

• 最初から作りこまない
• 業務に合わせて段階的に育てる

という姿勢です。

このあとの章では、
業務の現場で使いやすい Azure の主要コンポーネントを、
「業務データ」「処理」「データ管理」という視点で整理していきます。

業務で使いやすい Azure の主要コンポーネント

Azure というと、どうしても「インフラ」や「システム構築」というイメージが先に立ちがちですが、
実際の業務を見ていくと、最初に課題になるのは 処理 よりも データの置き場 であることが多くあります。

• ファイルが各所に散らばっている
• NAS やファイルサーバーが容量逼迫している
• 業務システムや Power Platform で扱うデータの置き場に困っている

こうした状況に対して、
Azure は「まずはデータを安全に、柔軟に置く場所」として使い始めることができます。

ここでは、業務を起点に考えたときに使いやすい Azure の主要コンポーネントを、
データの置き場 → 処理 → データ管理、という流れで整理していきます。

業務データの置き場として Azure Storage（Blob / Files）

業務で Azure を使い始める際、もっとも自然な入口の一つが Azure Storage です。
Azure Storage は、Azure 上でデータやファイルを保存するための基盤サービスで、
特に Blob Storage と Azure Files は業務用途でよく使われます。

Azure上でファイルを扱うための基本ストレージ。
Blobは非構造データ向け、Filesは共有フォルダ的な用途に向いており、業務データの起点になりやすいサービスです。
Blob Storage（公式）　https://learn.microsoft.com/azure/storage/blobs/
Azure Files（公式）　https://learn.microsoft.com/azure/storage/files/

Azure Storage が業務に向いている理由

業務データの置き場として Azure Storage が選ばれる理由は、とてもシンプルです。

• 容量を意識せずに使えるスケーラビリティ
• 従量課金で「使った分だけ」支払うモデル
• 99.9%以上の高い可用性と冗長性
• Azure や Power Platform との自然な連携

オンプレミスのファイルサーバーや NAS では、
容量増設やバックアップ、障害対策を常に意識する必要がありますが、
Azure Storage ではこれらを サービス側に任せる ことができます。

Blob Storage：業務ファイル・CSV・ログの置き場として

Azure Blob Storage は、画像・PDF・CSV・ログ・バックアップなど、
非構造化データ を大量に保存することを得意としたオブジェクトストレージです。

業務でよくある使い方としては、次のようなケースがあります。

• Power Apps や Power Automate で生成した CSV / 添付ファイルの保存先
• システムや業務アプリのログ保存先
• 画像・帳票・エビデンスファイルの保管
• 将来使うかもしれないデータの一時保管・アーカイブ

Blob Storage では、データの利用頻度に応じて
Hot / Cool / Archive などのアクセス層を使い分けることができ、
「普段使うデータ」と「ほとんど読まないデータ」を同じ仕組みで管理できます。

Azure Files：ファイルサーバー・NAS の代替として

Azure Files は、SMB や NFS プロトコルを使ってアクセスできる
クラウド上のファイル共有 サービスです。

これは、

• 既存のファイルサーバー
• 社内 NAS
• アプリケーションが参照する共有フォルダ

といった用途を、構成を大きく変えずにクラウドへ移行したい場合に適しています。

特に、

• 「アプリケーションを書き換えずに移行したい」
• 「まずはファイル置き場だけクラウドに逃がしたい」

といったケースでは、Azure Files を選ぶことで無理のない導入が可能です。

Blob か Files かを迷ったら

業務で使う際のざっくりとした考え方は次の通りです。

最初からどちらかに決め切る必要はなく、
用途ごとに併用するのが現実的なケースも多くあります。

「まずはデータの置き場を整理する」

Azure Storage は、
処理やシステムを作り込む前に、業務データを整理するための基盤 として非常に相性が良いサービスです。

このあとに紹介する Azure Functions や Azure Logic Apps、
さらには Cosmos DB や Azure SQL Database も、
多くのケースで Azure Storage を起点に連携していくことになります。

ちょっとした処理に Azure Functions / Azure Logic Apps

業務データの置き場がある程度整理できてくると、
次に出てくるのが「このデータに対して、ちょっと何かしたい」という要望です。
たとえば、

• ファイルが置かれたら通知したい
• CSVをアップロードしたら整形したい
• データを別システムに連携したい
• 定期的に処理を動かしたい

こうした要件に対して、
いきなりサーバーや VM を立てる必要はありません。

「必要なときだけ動く処理」を実現するための選択肢として、
Azure Functions と Azure Logic Apps があります。

Azure Functions：小さな処理をコードで任せる

いわゆる サーバーレス の仕組みで、
「特定のイベントをきっかけにコードを実行する」用途に向いています。

業務での典型的な使い方は、

• Blob Storage にファイルが置かれたら処理する
• HTTP リクエストを受けて軽い API 処理をする
• 定期実行でデータを整形・変換する

といった 小さく切り出した処理 です。
ポイントは、

• サーバーを常時起動しておく必要がない
• 処理が実行された分だけ課金される
• ロジックをシンプルに保ちやすい

という点です。
「ちょっとしたプログラムを書く場所」として、
非常に扱いやすい選択肢になります。

イベントをきっかけにコードを実行できるサーバーレス基盤。
ファイル登録やAPI呼び出しなど、「ちょっとした処理」を切り出すのに適しています。
公式ドキュメント　https://learn.microsoft.com/azure/azure-functions/

Azure Logic Apps：処理の流れを“つなぐ”

Azure 側で使える ローコードのワークフローサービス です。
考え方としては、

• 「どの順番で」
• 「どの条件で」
• 「どのサービスと連携するか」

といった 処理の流れそのもの を定義するためのもの、と捉えると分かりやすいです。
業務でよくある利用シーンとしては、

• ファイルが置かれたら → 処理 → 通知
• API を呼び出して → 結果を別システムに連携
• 複数の Azure サービスをまたいだ処理の自動化

などがあります。
コードを書くよりも
「業務フローを組み立てる」感覚 に近いため、

• 処理内容を関係者と共有しやすい
• ロジックがブラックボックス化しにくい

というメリットがあります。

さまざまなサービスをつなぎ、処理の流れをワークフローとして定義できる自動化サービス。
システム間連携や処理の可視化を重視したい場面に向いています。
公式ドキュメント　https://learn.microsoft.com/azure/logic-apps/

Power Automate との関係はどう考えるか

Logic Apps を見たときに、
Power Automate との違いが気になる方も多いと思います。

ここでは細かい比較には踏み込みませんが、
大まかな整理としては次のように捉えるとスムーズです。

実際の案件では、

• ユーザー操作に近い部分は Power Automate
• システム連携やバックエンド処理は Logic Apps / Functions

と役割を分けるケースも珍しくありません。

Functions × Logic Apps の組み合わせ

Azure Functions と Azure Logic Apps は、
どちらか一方を選ばなければならないものではありません。
たとえば、

• 処理の中身は Azure Functions
• 全体の流れや分岐は Logic Apps

といった形で組み合わせることで、

• 処理はシンプルに
• 全体像は分かりやすく

保つことができます。
VM のように「全部を1台に詰め込む」設計とは違い、
役割ごとに処理を分けられる のが、この辺りの Azure の強みです。

「軽い処理」を任せる、という割り切り

ここで大切なのは、

Azure Functions や Logic Apps にすべてを任せようとしないこと

です。

• 複雑な業務ロジック
• 大量データを前提とした処理
• 高度な分析や集計

こうしたものは、
後述するデータ管理サービスや別の仕組みに任せた方がよいケースも多くあります。
まずは、

• ちょっとした処理
• 小さな自動化
• 業務のつなぎ

から切り出す。
これが 「軽く使う Azure」 の考え方に合っています。

次につながる視点

ここまでで、

• 業務データの置き場（Azure Storage）
• それに対する軽い処理（Functions / Logic Apps）

が揃いました。
次に考えるのは、

「このデータ、どこまで管理する？」

という視点です。
続くセクションでは、
Azure Cosmos DB や Azure SQL Database を使った
データ管理の考え方を整理していきます。

Azure Cosmos DB で軽めのデータ処理・管理

Azure Storage と Azure Functions / Logic Apps を使い始めると、
次に出てくるのがこんな声です。

• CSV やファイルだけだと、検索がつらくなってきた
• データをキーで引きたい
• 状態管理や履歴を持たせたい
• 「一件ずつのデータ」として扱いたい

この段階になると、
ファイルの置き場（Storage）だけでは少し足りない
という感覚が出てきます。

そこで選択肢に入ってくるのが Azure Cosmos DB です。

スキーマに縛られすぎず、軽めのデータ管理を行えるフルマネージドDB。
処理結果の保持や状態管理など、中間的なデータ管理で力を発揮します。
公式ドキュメント　https://learn.microsoft.com/ja-jp/azure/cosmos-db/

Cosmos DB は「全部入りDB」ではない

最初に整理しておきたいのは、
Cosmos DB は 何でもできる万能データベースではない という点です。
むしろ向いているのは、

• データ量はそれなり
• スキーマはそこまで厳密でなくてよい
• 高速に読み書きしたい
• Azure Functions などから気軽に扱いたい

といった 軽めのデータ管理 です。
オンプレミスの SQL Server や
フル機能の RDB をそのまま置き換える、
という位置づけではありません。

「ファイル + 処理」の次の一歩として

業務的な流れで見ると、Cosmos DB が合う場面はとても分かりやすいです。
たとえば、

• Blob Storage に置いた CSV の内容を1件ずつ分解して保存したい
• 処理結果のステータスを持たせたい（処理中 / 完了 / エラー）
• Power Apps や API からID 指定でサッと取りたい

こうした用途では、

• ファイルとして持つには扱いづらい
• でも、いきなり SQL を立てるほどではない

という ちょうど中間 に位置します。

Azure Functions との相性が非常に良い

Cosmos DB の使いやすさは、
Azure Functions と組み合わせたときに特に実感できます。

• Functions で処理する
• 結果や状態を Cosmos DB に保存
• 必要なタイミングで参照する

という流れが、
とても自然に組める ためです。
しかも、

• スキーマをガチガチに決めなくてよい
• 小さなデータ単位で考えられる

ので、
業務ロジックを 重くしすぎずに済む のが大きなメリットです。

「NoSQL を理解しないと使えない？」という不安について

Cosmos DB を避けてきた理由として、
よく聞くのがこの不安です。

NoSQL って難しそう
設計を間違えたら取り返しがつかないのでは？

ですが、
軽めのデータ管理用途であれば、深く考えすぎる必要はありません。
この段階で大切なのは、

「どんな単位でデータを扱いたいか」
「どう取り出したいか」

この2点だけです。
複雑な JOIN や
重たいトランザクションが必要になってきたら、
それは Cosmos DB を卒業するサイン でもあります。

Cosmos DB は「中継地点」と考える

この記事の流れでいうと、
Cosmos DB は 最終ゴールではありません。

• Storage → ファイル管理
• Functions / Logic Apps → 処理
• Cosmos DB → 軽めのデータ管理

という流れの中で、

「とりあえず、ちゃんとした形でデータを持つ」

ための 中継地点 と考えると、非常に使いやすくなります。
無理に育て続けない。
必要になったら、次の選択肢へ進む。という点が重要です。

次に見えてくる選択肢

Cosmos DB を使っていく中で、
いずれこんな要求が出てきます。

• 複雑な検索条件を使いたい
• 集計・結合が増えてきた
• 業務ロジックと密接になってきた

この段階になったら、
Azure SQL Database を検討するタイミングです。
次のセクションでは、
Cosmos DB との住み分けを意識しながら、
Azure SQL Database をどう位置づけるかを整理していきます。

より複雑なデータ操作には Azure SQL Database

Azure Storage、Azure Functions / Logic Apps、そして Azure Cosmos DB まで使い始めると、
次の段階として、次のような要件が見えてきます。

• データ同士の関係を意識したくなってきた
• 集計や検索条件が複雑になってきた
• 業務ロジックとデータが密接に結びついてきた
• 「最終的に正」となるデータを、きちんと管理したい

この段階に来たら、Azure SQL Database を検討するタイミングです。

業務の正データを扱うためのフルマネージドSQLデータベース。
集計・検索・整合性が求められる段階で、構成の中核になります。
公式ドキュメント　https://learn.microsoft.com/azure/azure-sql/database/

Azure SQL Database は「きちんとした業務データの置き場」

Azure SQL Database は、
Microsoft SQL Server をベースにした フルマネージドのリレーショナルデータベース です。
ポイントは、

• テーブル定義が明確
• リレーション（関連付け）が組める
• SQL による複雑な検索・集計ができる

という、従来の業務システムで慣れ親しんだ特性を持っている点です。
一方で、

• OS 管理
• パッチ適用
• バックアップや高可用性

といった 運用の重たい部分は Azure 側に任せられる ため、
オンプレミスや VM 上で SQL Server を運用するよりも、
運用負荷を大きく下げることができます。

Cosmos DB との役割の違い

ここまで読んでいただいた方であれば、
Cosmos DB との住み分けはイメージしやすいと思います。
あらためて業務視点で整理すると、次のようになります。

Cosmos DB では少しつらくなってきた処理が、
Azure SQL Database では自然に書ける、
という場面は少なくありません。

「最初から SQL を選ばない」ことの意味

ここで強調しておきたいのは、
最初から Azure SQL Database を選ばなくてもよい という点です。
これまでの流れの通り、

1. ファイルとして扱う（Storage）
2. 軽く処理する（Functions / Logic Apps）
3. 軽めに管理する（Cosmos DB）
4. 複雑になってきたら SQL

という段階的な進め方は、
業務システムとしてとても自然です。
最初から SQL を前提にすると、

• 設計が重くなる
• 初期コストが上がる
• 変更に弱くなる

というデメリットも出てきます。
「必要になったら、より強い基盤へ移す」
この割り切りが、Azure を業務で使いやすくするコツです。

Power Platform との相性

Azure SQL Database は、
Power Apps や Power Automate などの Power Platform とも相性がよいサービスです。

• 業務アプリの裏側のデータベースとして使う
• 権限制御されたデータを安全に扱う
• 大量データを前提とした検索・参照を行う

といった用途では、
SharePoint リストや Dataverse では少し厳しいケースを補完できます。
「Power Platform だけでは足りない部分を、Azure SQL Database で支える」
という関係性も、現実的な構成の一つです。

Azure SQL Database は“ゴール”ではない

この記事の文脈で言えば、
Azure SQL Database もまた 万能なゴール ではありません。

• DWH（分析基盤）が欲しくなった
• BI 専用の構成にしたくなった
• AI・大規模分析につなげたい

といった場合には、
さらに別の Azure サービスを検討することになります。
ただし、
業務システムの中核となるデータ管理
という点では、Azure SQL Database は十分に強力で、
かつ扱いやすい選択肢です。

ここまでの全体像

ここまでの記事全体を振り返ると、
Azure の使いどころは次のように整理できます。

すべてを一気に導入する必要はありません。
業務の成長や変化に応じて、段階的に使い分ける

構成ができた後に考えるべきこと（運用・保護）

ここまでで、
Azure を使った業務向けの構成イメージは、かなり具体的になってきたと思います。
このタイミングで、よく話題に上がるのが
運用 と 保護（セキュリティ・データ保全） です。
ただし、最初に強調しておきたいのは、
ここですべてを決め切る必要はない ということです。

Azure を業務で使い始めると、

• ちゃんと動いているか
• エラーは分かるのか
• 予想外のコストが出ていないか

といった「運用」の話は、いずれ必ず出てきます。
とはいえ、最初から高度な監視や厳密なルールを用意すると、
構築よりも管理のための設計が前に出てしまいがちです。
まずは、

• どこが止まると業務に影響が出るのか
• どこは多少止まっても許容できるのか

こうした業務目線の整理ができていれば十分です。
Azure の良いところは、
動かしながら運用を強化できる余地がある ことです。
最初はシンプルに、必要になったところから整えていく、
この進め方が現場では無理がありません。

データを扱っている以上、
保護やセキュリティも避けては通れないテーマです。

• 誰がどこまでアクセスできるのか
• 誤って消えたとき、どう戻せるのか
• 外部とどう切り分けるのか

ただし、これも「最初から最大限」を目指す必要はありません。
扱うデータの内容や重要度によって、
必要なレベルは大きく変わります。
重要なのは、

いずれ強化する前提で、拡張できる構成にしておくこと

です。
Azure には、
後から段階的に保護を強められる仕組みが揃っています。
運用やセキュリティで最初の一歩を止めない、
そのくらいの距離感がちょうど良いケースも多くあります。

Microsoft 365 側のデータについては、Azure とは別に考える視点も重要です。
特に、Outlook や OneDrive、SharePoint などのデータ保護については、
Microsoft 365 Backup という選択肢もあります。

ここでは深掘りしませんが、
「業務が動き始めてから、どこまで守るかを整理する」
という考え方で、後から選択肢を広げられる構成にしておくことが大切です。

▶ Microsoft 365 Backup の考え方を整理した記事

Power Platformとの役割分担はどう考えるか

もう一つ、構成を考える中でよく聞かれるのが、
Power Platform と Azure の役割分担です。
この2つは、
「どちらを選ぶか」ではなく
「どこで使い分けるか」という関係にあります。

Power Platform は、

• 画面を作る
• 業務フローを組み立てる
• 現場主導で改善を回す

といった、人が触る前提の領域をとても得意としています。
業務部門や現場担当者が主体となって使う場合、
Power Platform は非常に相性の良い選択肢です。

一方で Azure は、

• データの置き場
• バックエンド処理
• システム間連携

といった、人が直接触らなくてもよい裏側を支える役割に向いています。
安定して、黙々と動いてくれればよい部分を Azure に寄せることで、
全体の構成はシンプルになります。

迷ったときは、
次の問いで切り分けると考えやすくなります。

この考え方だけでも、
設計の判断はかなり楽になります。
すべてを Power Platform で完結させようとしない。
すべてを Azure に集約しようとも思わない。
それぞれの得意な領域に役割を置くことで、
無理のない構成になります。

運用・保護も、役割分担も、
最初から完成形を作る必要はありません。

小さく始める
実際に使われる
必要に応じて整える

この前提で構成しておけば、
業務の変化にも自然に対応できます。
Azure と Power Platform は、
そのための余地をきちんと残して使える、
という点を押さえておけば十分です。

まとめ

Azureというと、今でも「まずはVM」というイメージを持たれがちです。
しかし実際の業務を見ていくと、すべてがVMを前提である必要はありません。

• データの置き場として使う。
• ちょっとした処理だけを任せる。
• 軽めのデータ管理から始める。

こうした小さな単位でAzureを使い始めることで、
構成は自然にシンプルになり、運用の負担も抑えやすくなります。

重要なのは、最初から完成形を目指さないことです。
業務にあわせて、必要になったところから段階的に育てていく。
この記事が、
「 Azure をどう使うか」を考える際の、一つの整理軸になれば幸いです。

参考：各サービスの公式ドキュメント