この記事のポイント
Azure Queue Storageの基本概念と構成要素（ストレージアカウント・キュー・メッセージ）を図解付きで解説- スケーラビリティ仕様（アカウントあたり毎秒20,000メッセージ、キュー最大500TiB）やTTL設定、冗長性オプションを網羅
- Azureポータルでのキュー作成手順に加え、Azure Functionsとの連携方法を紹介
- Service Bus Queueとの機能差を比較表で整理し、選定基準を提示
- 2026年3月時点の料金体系（GPv2アカウント、冗長性別ストレージ料金、操作料金）を解説
Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
Azure Queue Storageは、アプリケーション間で情報を非同期にやり取りするためのクラウドメッセージングサービスです。
Microsoft Azureが提供するストレージサービスの一つで、キュー（待ち行列）にメッセージを一時保存し、バックエンドのワーカーが順番に処理する仕組みを手軽に構築できます。
本記事では、Azure Queue Storageの基本概念からスケーラビリティ仕様、Azure Functionsとの連携方法、Service Bus Queueとの違い、料金体系までを体系的に解説します。
Azureでの非同期処理やマイクロサービス設計を検討している方に向けた内容です。
Azureの基本知識や料金体系についてはこちらの記事で詳しく解説しています。
Microsoft Azureとは？できることや各種サービスを徹底解説
Microsoft 365 Copilotの最新エージェント機能「Copilot Cowork」については、以下の記事をご覧ください。
Copilot Coworkとは？機能や料金、Claude Coworkとの違いを解説
Azure Queue Storageとは
Azure Queue Storage（キューストレージ）は、クラウド上でメッセージを一時保存し、アプリケーション間で情報を非同期にやり取りするためのメッセージングサービスです。Azure Storageインフラストラクチャの一部として提供されており、HTTP/HTTPSを使用して世界中のどこからでもアクセスできます。
たとえば、ECサイトで注文が集中した場合を考えてみましょう。注文処理をすべてリアルタイムでデータベースに書き込もうとすると、アクセスが集中してレスポンスが遅延し、最悪の場合はシステムがダウンします。Azure Queue Storageを間に挟めば、ユーザーからのリクエストをキュー（待ち行列）に一時保存し、バックエンドのワーカーが順番に処理する構成を取れます。ユーザーは処理完了を待たずにアプリケーションを使い続けられるため、体感速度が大きく改善します。
このように、Azure Queue Storageは非同期処理の実装を手軽にする基盤として、Webアプリケーション、バッチ処理、マイクロサービスアーキテクチャなど幅広い場面で活用されています。
非同期メッセージングの仕組み
Azure Queue Storageが採用する非同期メッセージングとは、送信側と受信側がリアルタイムに接続されていなくても情報をやり取りできる通信方式です。
直接データベースに書き込む同期的な処理には、以下の問題があります。
- 処理の遅延
ユーザーからのリクエストが集中すると、データベースへのアクセスが競合し、レスポンスタイムが悪化します。ユーザーにとっては「画面が固まる」ストレスにつながります。
- スケーラビリティの制約
リクエスト量が増えても、同期処理ではすべてを同時に処理しなければなりません。データベースの処理能力がボトルネックとなり、システム全体の拡張が難しくなります。
Queue Storageを間に挟むことで、送信側はメッセージをキューに追加するだけで済み、受信側は自分のペースでメッセージを取り出して処理できます。この分離によって、送信側と受信側それぞれを独立してスケールさせることが可能になります。
Queue Storageの構成要素
Azure Queue Storageは、3つのコンポーネントで構成されています。
| 構成要素 | 役割 |
|---|---|
| ストレージアカウント | Queue Storageを含むすべてのAzure Storageサービスへのアクセスを管理する最上位のリソース |
| キュー | メッセージを格納する待ち行列。キュー名は小文字で3〜63文字 |
| メッセージ | キュー内に格納される個々のデータ。最大64KBで、形式は問わない |
キューには一意のURLが割り当てられ、以下の形式でアクセスします。
https://<ストレージアカウント名>.queue.core.windows.net/<キュー名>
ストレージアカウントの総容量を超えない限り、1つのキューに数百万件のメッセージを格納できます。メッセージの最大サイズは64KBですが、Base64エンコードを使用する場合は実質48KBが上限となる点に注意が必要です。
Azure Queue Storageの主要機能と仕様
Azure Queue Storageは、シンプルなAPIでありながら大規模な非同期処理に対応できるスケーラビリティを備えています。ここでは、設計時に把握しておくべき主要な仕様を解説します。
スケーラビリティとパフォーマンス
Azure Queue Storageのスケーラビリティターゲットは、以下のとおりです。
| 項目 | 上限値 |
|---|---|
| 1つのキューの最大サイズ | 500 TiB |
| メッセージの最大サイズ | 64 KiB（Base64エンコード時は48 KiB） |
| ストレージアカウントあたりの最大リクエストレート | 毎秒20,000メッセージ（1 KiBメッセージ想定） |
| 1つのキューのターゲットスループット | 毎秒最大2,000メッセージ（1 KiBメッセージ想定） |
| キューあたりの保存アクセスポリシー | 最大5 |
アカウントあたり毎秒20,000メッセージという処理能力は、多くのWebアプリケーションやバッチ処理に十分対応できる水準です。1つのキューで処理能力が不足する場合は、複数のキューに負荷を分散させる設計が推奨されます。
ワークロードがパーティションの処理上限に達すると、Azure Storageはエラーコード503（サーバービジー）または500（タイムアウト）を返します。この場合は、エクスポネンシャルバックオフ（指数的に待機時間を延ばすリトライ戦略）の導入が有効です。
メッセージの有効期間（TTL）と可視性タイムアウト
メッセージの有効期間（TTL: Time-To-Live）とは、メッセージがキューに保持される期間を指します。
- デフォルトTTL
7日間。この期間を過ぎると、メッセージは自動的に削除されます。
- 無限TTLの設定
APIバージョン2017-07-29以降では、TTLを-1に設定することでメッセージを無期限に保持できます。長期間の処理待ちが発生するバッチ処理などで有効です。
- 可視性タイムアウト
メッセージがデキュー（取り出し）されると、他のワーカーには一定期間「見えなく」なります。デフォルトは30秒で、最大7日間まで延長可能です。処理中にワーカーがクラッシュした場合、可視性タイムアウトが切れた時点でメッセージが再び表示され、別のワーカーが処理を引き継ぎます。
この仕組みにより、メッセージの取りこぼしを防ぎながら、複数のワーカーで並列処理を行うことができます。
冗長性オプション
Azure Queue Storageは、Azureストレージアカウントの冗長性設定を継承します。用途に応じて、以下の6つのオプションから選択できます。
| 冗長性 | データの複製先 | 特徴 |
|---|---|---|
| LRS（ローカル冗長） | 同一データセンター内に3重複製 | 最低コスト。データセンター障害には非対応 |
| ZRS（ゾーン冗長） | 同一リージョン内の3つの可用性ゾーン | データセンター単体の障害に耐性あり |
| GRS（地理冗長） | プライマリ＋セカンダリリージョン（計6コピー） | リージョン障害に対応。セカンダリは読み取り不可 |
| RA-GRS（読み取りアクセス地理冗長） | GRSと同じ構成 | セカンダリリージョンからの読み取りが可能 |
| GZRS（ゾーン冗長＋地理冗長） | プライマリ3ゾーン＋セカンダリリージョン | ZRSとGRSの組み合わせ。最も高い耐障害性 |
| RA-GZRS（読み取りアクセスGZRS） | GZRSと同じ構成 | セカンダリからの読み取りも可能 |
コストとの兼ね合いで選ぶ必要がありますが、本番環境ではZRS以上を推奨します。メッセージの消失が許容されるワークロード（一時的なジョブキューなど）であればLRSでも問題ありません。
Azure Queue Storageの使い方
Azure Queue Storageを利用するには、まずAzureポータルでストレージアカウントを作成し、その中にキューを追加します。ここでは、ポータルを使った基本的な作成手順と、Azure Functionsとの連携方法を解説します。
Azureポータルでのキュー作成手順
以下の手順でQueue Storageを作成できます。
1. Azureポータルにログイン
Azureポータルにアクセスし、アカウントでログインします。
2. ストレージアカウントの作成
ダッシュボードの「リソースの作成」から「ストレージアカウント」を選択します。サブスクリプション、リソースグループ、ストレージアカウント名、リージョン（Japan Eastなど）を入力し、「確認および作成」をクリックします。
ストレージアカウントの作成
3. キューサービスの選択
ストレージアカウントの概要ページから「キュー」セクションを選択します。
キューサービスの利用ページ
4. キューの作成
「+ キュー」をクリックし、キュー名を入力します。キュー名は小文字・数字・ハイフンのみ使用でき、3〜63文字の範囲で指定します。
キューの作成
5. メッセージの追加
キューが作成されたら、「メッセージの追加」からメッセージを送信できます。メッセージの有効期限や可視性タイムアウトもここで設定可能です。
キューよりメッセージの追加
本番環境では、ポータルからの手動操作ではなく、SDKやAzure CLIを使ったプログラムからの操作が一般的です。.NET、Java、Python、JavaScript、Go向けのSDKが提供されています。
Azure Functionsとの連携
Azure Functionsは、Azure Queue Storageと組み合わせて使われることが多いサービスです。キューにメッセージが追加されたことをトリガーに関数を自動実行する仕組みにより、イベント駆動型のアーキテクチャを構築できます。
Azure FunctionsのQueue Storage連携には、2つのバインドが用意されています。
| バインドの種類 | 動作 |
|---|---|
| Queue Storageトリガー | キューに新しいメッセージが追加されると関数を自動実行 |
| 出力バインド | 関数の実行結果をキューメッセージとして書き込み |
たとえば、ユーザーが画像をアップロードした際に、Blob Storageへの保存完了メッセージをキューに追加し、そのメッセージをトリガーにサムネイル生成関数が起動する、という処理フローが実現できます。
トリガーの動作は、host.jsonファイルで細かく調整できます。同時処理するメッセージ数（batchSize、デフォルト16）、ポーリング間隔（maxPollingInterval、デフォルト1分）、有害メッセージの最大試行回数（maxDequeueCount、デフォルト5）などを、ワークロードの特性に合わせて設定します。
なお、Azure Functionsの.NETインプロセスモデルは2026年11月10日にサポートが終了するため、新規開発では分離ワーカーモデルの採用が推奨されています。
Azure Queue StorageとService Bus Queueの違い
Azureには、メッセージキューサービスとしてQueue StorageのほかにService Bus Queueがあります。名前が似ているため混同されがちですが、設計思想と対象ユースケースが異なります。
Queue Storageはシンプルさとコスト効率を重視した設計で、大量のメッセージを低コストに格納・処理するのに向いています。一方、Service Bus Queueはエンタープライズレベルの高度なメッセージング機能を備え、トランザクション処理や厳密な順序保証が求められるシナリオに適しています。
以下の表で、主要な違いを整理しました。
| 比較項目 | Queue Storage | Service Bus Queue |
|---|---|---|
| メッセージサイズ上限 | 64 KB | Standard: 256 KB / Premium: 1 MB（最大100 MBまで対応可） |
| キューサイズ上限 | 500 TiB（ストレージアカウント容量に依存） | 1 GB〜80 GB |
| FIFO順序保証 | なし（概ね先入先出だが保証なし） | あり（メッセージセッション使用時） |
| 配信保証 | At-Least-Once | At-Least-Once（PeekLock） / At-Most-Once（ReceiveAndDelete） |
| デッドレターキュー | なし（アプリ側で実装） | あり（自動振り分け） |
| 重複検出 | なし | あり |
| トランザクション | なし | あり（ローカルトランザクション対応） |
| スケジュール配信 | あり（可視性タイムアウトで実現） | あり（専用API） |
| 受信方式 | ポーリング（非ブロッキング） | 長いポーリング / プッシュ型API |
| プロトコル | HTTP/HTTPS REST | AMQP 1.0 / HTTP/HTTPS REST |
| サーバー側トランザクションログ | あり | なし |
| 同時クライアント数 | 無制限 | 5,000（TCP接続時は100/キュー） |
この比較から分かるのは、機能の豊富さではService Bus Queueが上回るものの、Queue Storageには「500 TiBまでの大容量」「無制限のクライアント接続」「サーバー側ログ」といった固有の強みがあるという点です。
選び方の判断基準
どちらを選ぶかは、アプリケーションの要件で決まります。
Queue Storageが適している場面は以下のとおりです。
- 80 GBを超える大量のメッセージを格納する必要がある
- メッセージ処理の進行状況をサーバー側ログで追跡したい
- シンプルな非同期処理で、高度なメッセージング機能は不要
- コストを最小限に抑えたい
Service Bus Queueが適している場面は以下のとおりです。
- 厳密なFIFO順序保証が必要
- デッドレターキューや重複検出を使いたい
- 64 KBを超えるメッセージを扱う
- AMQP 1.0プロトコルでの接続が求められる
- 将来的にパブリッシュ/サブスクライブパターンへの拡張を想定している
迷ったら、まずQueue Storageから始めるのが実践的です。機能が不足した段階でService Bus Queueへの移行を検討しても遅くありません。
Azure Queue Storageの活用シナリオ
Azure Queue Storageは、非同期処理が求められる多様な場面で価値を発揮します。ここでは代表的な2つのシナリオを紹介します。
Webアプリケーションのバックグラウンド処理
ECサイトやSaaSアプリケーションでは、ユーザーのリクエストに対してすべての処理をリアルタイムで完了させる必要はありません。
たとえば、注文確認メールの送信、在庫データの更新、配送ステータスの記録といった処理は、ユーザーへの即時応答とは切り離してバックグラウンドで実行できます。Queue Storageにリクエストを一時保存し、バックエンドのワーカーが非同期に処理することで、フロントエンドの応答速度を維持しつつ、バックエンドの負荷を平準化できます。
トラフィックが急増するセール期間やキャンペーン時にも、キューがバッファとして機能するため、バックエンドシステムが過負荷でダウンするリスクを軽減できます。
マイクロサービス間の非同期通信
マイクロサービスアーキテクチャでは、各サービスが独立してデプロイ・スケールできることが設計の基本です。サービス間を直接API呼び出しで結合すると、一方のサービスがダウンした際に連鎖的に障害が広がる「カスケード障害」のリスクがあります。
Queue Storageをサービス間の通信レイヤーとして挟むことで、サービス間の結合度を下げられます。送信側はメッセージをキューに投入するだけで処理が完了し、受信側は自分のペースでメッセージを取り出して処理します。
大規模なデータ処理では、ジョブを小さなタスクに分割してキューに投入し、複数のワーカーが並列に処理するパターンも広く使われています。ビッグデータ分析や機械学習モデルのトレーニングデータ前処理など、処理量が読めないワークロードに対してキューベースの設計は有効です。
毎日の注文処理やデータ連携で「処理が詰まって後続のバッチが遅延する」という課題を抱えているなら、キューを挟んだ非同期設計への移行を検討する価値があります。
【関連記事】
Azure Event Gridとは？イベント配信の仕組みと活用事例を徹底解説
Azure Queue Storageの注意点
Azure Queue Storageはシンプルで扱いやすいサービスですが、設計時に把握しておくべき制約と注意事項があります。
メッセージサイズとFIFO保証の制約
Azure Queue Storageを使ううえで、特に注意すべき制約は以下の3点です。
- メッセージサイズ上限は64 KB
大きなデータを扱いたい場合は、メッセージ本文にデータそのものではなく、Blob Storageに保存したデータへの参照URLを格納する設計が推奨されます。キューとBlobを組み合わせることで、1アイテムあたり最大200 GBまでのデータを間接的に扱えます。
- FIFO順序は保証されない
Queue Storageのメッセージは概ね先入先出で処理されますが、厳密な順序保証はありません。ワーカーがメッセージ処理中にクラッシュすると、可視性タイムアウトの期限切れ後にメッセージが再表示され、後から投入されたメッセージよりも後に処理される場合があります。順序保証が必須な場合は、Service Bus Queueのメッセージセッション機能を検討してください。
- ポイズンメッセージの処理
処理に繰り返し失敗するメッセージ（ポイズンメッセージ）は、アプリケーション側でDequeueCountプロパティを監視し、一定回数を超えたら専用のエラーキューに移動する設計が必要です。Service Bus Queueのように自動的なデッドレターキューは提供されていません。
セキュリティと認証
Azure Queue Storageは、以下の認証方式をサポートしています。
- Microsoft Entra ID（旧Azure AD）
ロールベースのアクセス制御（RBAC）と組み合わせて、ユーザーやアプリケーションに最小限の権限を付与できます。本番環境ではこの方式が推奨されます。
- 共有アクセス署名（SAS）
期限付きの限定的なアクセス権限を発行できます。外部パートナーとの一時的な連携や、クライアントアプリケーションに直接アクセスを許可する場合に利用します。
- ストレージアカウントキー
フルアクセス権限を持つ対称キーです。開発・テスト環境では手軽に使えますが、本番環境ではキーの漏洩リスクがあるため、Entra IDまたはSASへの移行を推奨します。
すべてのリクエストは認証が必須であり、匿名アクセスのパブリックキューはサポートされていません。Azure Monitorと組み合わせてアクセスログを監視することで、不正アクセスの早期検知にも対応できます。
Azure Queue Storageの料金
Azure Queue Storageの料金は、ストレージ容量と操作回数に基づく従量課金制です。General Purpose v2（GPv2）ストレージアカウントでの利用が標準であり、GPv1と比較してGB単価が安く設定されています。
料金は、以下の3つの要素で構成されます。
- ストレージ容量（GB/月）
格納されているメッセージの総容量に対して課金されます。冗長性オプション（LRS / ZRS / GRS / RA-GRS / GZRS / RA-GZRS）によって単価が異なり、LRSが最も安価です。
- 操作料金（10,000操作あたり）
キュー操作はクラス1とクラス2に分類されます。クラス1にはPutMessage、DeleteMessage、CreateQueueなどの書き込み系操作が、クラス2にはGetMessage、PeekMessageなどの読み取り系操作が含まれます。
- データ転送料金
同一リージョン内の転送は無料です。GRS / RA-GRSの地理レプリケーション転送は追加料金なしで提供されています。リージョン間のアウトバウンド転送にはGB単位の料金が発生します。
料金の具体的な金額はリージョンや為替レートによって変動するため、最新の正確な料金はAzure Queue Storageの公式料金ページまたはAzure料金計算ツールで確認してください。
Queue Storageの料金水準は、Azureのメッセージングサービスの中でも最低クラスです。シンプルな非同期処理であれば、月額数十円〜数百円程度で運用できるケースも多いため、コスト面のハードルは非常に低いサービスといえます。
【関連記事】
Azureの料金体系を解説！サービスごとの料金例や確認方法も紹介
【無料DL】AI業務自動化ガイド（220P）
Microsoft環境でのAI活用を徹底解説
Microsoft環境でのAI業務自動化・AIエージェント活用の完全ガイドです。Azure OpenAI、AI Agent Hub、n8nを活用した業務効率化の実践方法を詳しく解説します。
まとめ
本記事では、Azure Queue Storageの基本概念からスケーラビリティ仕様、Azure Functionsとの連携、Service Bus Queueとの比較、注意点、料金体系までを解説しました。
Azure Queue Storageが提供する価値は、以下の3点に集約されます。
- シンプルなAPIによる非同期処理の実装
HTTP/HTTPS RESTベースのインターフェースで、アプリケーション間の疎結合を実現できる
- 大規模ワークロードへのスケーラビリティ
アカウントあたり毎秒20,000メッセージ、キュー最大500 TiBという処理能力で、トラフィック急増にも対応できる
- Azureエコシステムとの統合
Azure Functions、Blob Storage、Logic Appsなど他のAzureサービスとの連携により、イベント駆動型アーキテクチャを構築できる
まずはAzureの無料アカウントでストレージアカウントを作成し、ポータルからキューを1つ作ってメッセージの追加・取得を試してみてください。Queue Storageの動作を体感できれば、自社のどの処理を非同期化すべきかの判断材料が得られるはずです。
