Azure Cloud Shellの使い方｜起動手順・料金・ストレージの選び方と制限【2026年10月】

Azure Cloud Shellは、Azureポータルやブラウザから開ける認証済みのターミナルです。Azure CLIやAzure PowerShellをローカルに入れなくても、サインインしたアカウントの権限でそのままコマンドを打てます。シェルの実行環境は無料ですが、永続化用のAzure Files、仮想ネットワーク展開に必要なネットワークリソース、操作によって作成したVMなどには別途料金がかかります。この記事では、初回の登録と起動、VMを作ってSSHで入るまでの実例、ファイルの受け渡し、ストレージの選び方、20分タイムアウトなどの制限と起動エラーの対処を、Microsoft Learnの公式ドキュメントとCloud Shellのイメージ定義（GitHub）で確認した内容に沿って解説します（2026年10月時点）。

まとめ：Azure Cloud Shellの要点

• 料金：シェルの実行環境は無料。永続化用のAzure Files共有には料金がかかる。標準のエフェメラルセッション自体は無料だが、作成したVMなどのリソースや仮想ネットワーク展開の費用は別途発生する。
• 起動：ポータル上部のアイコンか shell.azure.com。初回はサブスクリプションに Microsoft.CloudShell リソースプロバイダーを登録しておく。
• ストレージ：使い捨てならエフェメラル、SSH鍵やスクリプトを残すなら永続ストレージ。エフェメラルで az vm create --generate-ssh-keys を実行すると、作った鍵はセッション終了で消える。
• 制限：無操作20分でセッション終了、テナントあたり同時20ユーザーまで、sudo は使えない。長時間のジョブや大量コピーには向かない。
• ツール：Azure CLI・Azure PowerShell・Bicep・Terraform・kubectl・Gitなどが導入済み。公式一覧の言語バージョン表記は古く、実際の版はシェル内のコマンドで確認する。

以下、起動手順から順に見ていきます。

Azure Cloud Shellとは：ブラウザで開く認証済みのBash・PowerShell環境

シェルとは、コマンドを受け取ってOSに実行させる対話型のプログラムのことで、LinuxのBashやWindowsのPowerShellが代表例です。Azure Cloud Shellは、このシェルをAzureがブラウザ越しに提供するサービスで、公式ドキュメントでは「Azureリソースを管理するための、認証済みで構成済みのブラウザーベースのターミナル」と説明されています（Microsoft Learn「Azure Cloud Shell の概要」）。

中身は、Microsoftのクラウド向けLinuxディストリビューション「Azure Linux」上で動くコンテナです。セッションごと・ユーザーごとに一時的なホストが割り当てられ、ブラウザとはWebSocketでつながります。コンテナにはサインイン中のユーザーのトークンを発行するエンドポイントが用意されているため、az login や Connect-AzAccount を打たなくても、開いた時点で自分のRBAC権限の範囲でリソースを操作できます。逆に言えば、Cloud Shellの中で実行したコマンドは、ポータルでの操作と同じく自分の権限で本番環境に効きます。

開ける入口はAzureポータル（portal.azure.com）、専用URLの shell.azure.com、Azureモバイルアプリ、Microsoft Learnの「Cloud Shellで開く」ボタン、Windows Terminal、VS Code for the Webです。どこから開いても同じユーザー設定とストレージが使われます。

Azure Cloud Shellの使い方：初回の登録から最初のコマンドまで

Microsoft.CloudShellリソースプロバイダーの登録

Cloud Shellを使う前に、サブスクリプションで Microsoft.CloudShell リソースプロバイダーを登録する必要があります。登録はサブスクリプションごとに1回で済みます（Microsoft Learn「エフェメラル セッションの使用を開始する」）。

1. Azureポータルで「サブスクリプション」を検索して開き、対象のサブスクリプションを選ぶ。
2. 左メニューの「設定」から「リソース プロバイダー」を開く。
3. 検索ボックスに cloudshell と入力し、Microsoft.CloudShellを選んで「登録」を押す。状態が「Registered」になれば完了。

ローカルにAzure CLIがある場合は az provider register --namespace Microsoft.CloudShell でも登録できます。サブスクリプションに対するリソースプロバイダーの登録権限が必要です。この権限は共同作成者・所有者ロールに含まれ、権限がない場合は管理者に依頼します。

起動とストレージの選択

ポータル上部のナビゲーションにあるCloud Shellアイコン（>_）を押すか、shell.azure.com を開きます。初回は次の順に選択を求められます。

1. 使用するシェルとして「Bash」か「PowerShell」を選ぶ。後からツールバーの「Switch to PowerShell／Switch to Bash」で切り替えられる。
2. 「Getting started」画面で、ストレージ無しの「No storage account required」（エフェメラル）か、「Mount storage account」（永続ストレージ）を選ぶ。
3. 使うサブスクリプションを選んで「Apply」を押す。永続ストレージを選んだ場合は、ストレージアカウントを自動作成するか既存のものを指定する。

迷ったら、最初はエフェメラルで動作を確かめ、ファイルを残す必要が出てから永続ストレージへ切り替えれば十分です。なお、ツールバーが文字のメニューに変わった新しい画面が2026年8月7日に全リージョンで標準になり、旧画面は撤去されました。アイコンだけが並ぶ旧画面のスクリーンショットで書かれた解説とは見た目が異なります。シェルを指定して開きたい場合は、https://portal.azure.com/?feature.azureconsole.shell=bash#cloudshell（PowerShellなら shell=pwsh）のURLも使えます。

サブスクリプションの確認と切り替え

開いたら最初に、操作対象のサブスクリプションを確認します。複数のサブスクリプションに権限があると、意図しない環境にリソースを作る事故が起きやすいためです。

# Bash（Azure CLI）
az account list --output table
az account set --subscription '<サブスクリプション名またはID>'
az account show --query name --output tsv

# PowerShell（Azure PowerShell）
Get-AzSubscription
Set-AzContext -Subscription '<SubscriptionId>'
Get-AzContext

選んだサブスクリプションは /home/<user>/.azure/azureProfile.json に記録されます。永続ストレージを使っていれば次回も引き継がれますが、エフェメラルでは毎回やり直しです。PowerShellでは cd Azure: で Azure: ドライブに移り、サブスクリプションやリソースをフォルダーのように辿れます。ポータル側で変更したリソースは dir -Force を実行すると表示に反映されます。

Bashでのリソースグループ・VM作成とSSH接続の実例

Cloud Shellの典型的な使い方は、ポータルでは手数が多い操作をコマンドでまとめて流すことです。次の例は、東日本リージョンにリソースグループとUbuntuのVMを作り、SSHで入って最後に片付けるまでの流れです。

az group create --name rg-cloudshell-demo --location japaneast

az vm create \
  --resource-group rg-cloudshell-demo \
  --name vm-demo \
  --image Ubuntu2404 \
  --admin-username azureuser \
  --generate-ssh-keys

# 出力の publicIpAddress を使って接続
ssh azureuser@<publicIpAddress>

# VM上の検証が終わったらSSH接続を終了してCloud Shellへ戻る
exit

# Cloud Shellでリソースグループごと削除
az group delete --name rg-cloudshell-demo --yes --no-wait

ここで注意したいのが --generate-ssh-keys の鍵の置き場所です。鍵はCloud Shellの ~/.ssh に作られます。エフェメラルセッションでは、ウィンドウを閉じてセッションが終わると、この秘密鍵も一緒に消えます。翌日同じVMに入ろうとしても鍵が無く、VMのパスワードリセット機能で鍵を入れ直すことになります。VMを数日以上使う予定があるなら、永続ストレージで起動するか、作成直後に秘密鍵をダウンロードして手元に保管してください。チームで共有する鍵や接続文字列は、Cloud Shellのホームに置かずAzure Key Vault（シークレット・キー・証明書の一元管理）に入れるのが公式の推奨でもあります。

パブリックIPを持たないVMには、このままではSSHできません。Cloud ShellはMicrosoft側のネットワークで動いており、自分の仮想ネットワーク内のプライベートIPには届かないためです。対処は後述の「仮想ネットワーク内のリソースに届かない」で扱います。

ファイルの受け渡しとエディター・Webプレビューの使い方

ファイルのアップロードとダウンロード

ツールバーの「Manage files」メニューから「Upload」を選ぶと、手元のファイルが /home/<user> に置かれます。ファイルをCloud Shellのウィンドウへドラッグしても同じです。複数ファイルを一度に送れますが、フォルダーはアップロードできないため、ディレクトリごと渡したいときは手元でzipにしてから送り、Cloud Shell側で unzip します。

「Download」はファイルのフルパスを入力する方式です。Cloud Shellのパスは大文字と小文字を区別するので、pwd と ls で正確なパスを確かめてから入力します（Microsoft Learn「Azure Cloud Shell の使用方法」）。

Cloud ShellエディターとVS Code for the Web

ツールバーの「Editor」ボタン、またはシェルで code .（特定のファイルなら code main.bicep）と打つと、ウィンドウ上半分にエディターが開きます。VS Codeと同じMonaco Editorがベースで、構文の色分け・コマンドパレット（F1）・ファイルエクスプローラーが使えます。保存はCtrl+S、閉じるのはCtrl+Qです。vim・nano・emacsも入っています。

複数ファイルをまたいで編集するなら、ツールバーの「Open in VS Code for the Web」を選ぶと、同じCloud Shellのコンテナにつながったブラウザ版VS Codeが新しいタブで開きます。ファイルエクスプローラーと統合ターミナルがそろうので、BicepやTerraformのファイルを数本まとめて直す作業はこちらが楽です。Azure Bicepのbuildとデプロイの手順やTerraformでAzureを構築する手順は、どちらもCloud Shellにツールが入っているため、そのまま試せます。

Webプレビューのポート開放とブラウザ表示

Cloud Shell内で動かしたWebアプリを確認したいときは、ツールバーの「Web preview」で番号を指定してポートを開きます。「Open port」は開くだけ、「Open and browse」は開いて新しいタブで表示します。たとえば python3 -m http.server 8080 を起動して8080を開けば、ブラウザから中身を確認できます。使い終わったら同じメニューの「Close port」で閉じます。

Azure Cloud Shellの料金：無料の実行環境と別途課金されるストレージ・リソース

公式の料金ページは「Cloud Shellは無料のサービスで、消費した基盤のAzureリソースにだけ支払う」としています（Microsoft Learn「Azure Cloud Shell の価格」）。内訳は次のとおりです。

永続ストレージの料金は、保存容量・アクセス層・操作回数によって変わります。公式概要は、$HOME の永続化に5GBのファイル共有を使うと説明しています。Azureの公開価格API（Azure Retail Prices API）で東日本リージョンのAzure Files（Standard・LRS）の保存単価を引くと、トランザクション最適化が1GBあたり月0.06ドル、ホットが0.03ドルでした（2026年10月28日取得）。5GB分を保存した場合の保存料金は月0.15〜0.30ドル程度で、これに読み書きのトランザクション料金（ホットではメタデータの保存料金も）が加わります。clouddrive に大きなファイルを置けば、その分だけ保存料金も増えます。為替や改定で変わるため、正確な金額はAzure Filesの価格ページで確認してください。

見落としやすいのは、ストレージアカウントをあとから自分で消さない限り課金が続く点です。Cloud Shellをやめるときは、自動作成された cloud-shell-storage-<リージョン> のようなリソースグループやストレージアカウントを確認して削除します。Cloud Shellで作ったストレージアカウントには ms-resource-usage:azure-cloud-shell というタグが付くので、ポータルのタグ絞り込みで探せます。

エフェメラルと永続ストレージの選び方

エフェメラルセッションは、ストレージアカウントを作らずに始められるモードです。ウィンドウを閉じるかCloud Shellを再起動するとセッションが終わり、保存したファイルはすべて削除されます。永続ストレージを選ぶと、Azure Filesの共有がマウントされ、次回以降もファイルが残ります。

判断の基準は「次のセッションに持ち越したいものがあるか」です。調査のためにコマンドを数本打つ、他部署のサブスクリプションを一時的に確認する、セッション終了後にCloud Shell内の作業ファイルを残したくない、といった用途はエフェメラルが向いています。ただし、共有PCのブラウザ履歴やサインイン状態を消す機能ではありません。一方、SSH鍵・自作スクリプト・Terraformの作業ディレクトリ・pip install --user で入れたモジュールを翌日も使うなら、永続ストレージを選びます。

永続ストレージの仕組みとアクセス権の注意

永続ストレージでは2つの方法でファイルが残ります。1つは $HOME ディレクトリ全体をディスクイメージにしてファイル共有の .cloudconsole/acc_<user>.img に保存する方法、もう1つはファイル共有そのものを $HOME/clouddrive にマウントする方法です。clouddrive に置いたファイルはポータルのストレージブラウザーからも見えます。$HOME の外に置いたファイルやマシンの状態は残りません（Microsoft Learn「Azure Cloud Shell でのファイルの永続化」）。

ただし公式ドキュメントの中でも説明が揃っていません。永続化のページと機能ページは「$HOME はイメージとして同期される」とする一方、FAQは「$HOME のファイルはストレージブラウザーに表示されず、セッション終了時に削除される」と書いています。消えて困るスクリプトや成果物は、ストレージブラウザーで実体を確認できる clouddrive に置くのが確実です。

注意したいのは権限の継承です。ストレージアカウントはサブスクリプション内の通常のリソースなので、そのサブスクリプションに十分な権限を持つ他のユーザーは、あなたの $HOME イメージ（SSH鍵やアクセストークンを含みうる）にアクセスできます。公式も「ユーザーごとに自分のストレージアカウントを作り、ストレージアカウントかサブスクリプションの単位で権限を絞る」よう求めています。共用サブスクリプションに置くなら、ストレージアカウントのアクセス制御（IAM）を確認しておきます。

エフェメラルから永続ストレージへの切り替え

エフェメラルで使い始めたあとに永続ストレージへ移るには、ツールバーの「Settings」から「Reset User Settings」を選びます。現在のセッションが閉じて初回の選択画面に戻るので、「Mount storage account」を選び直します。反対に、マウント中の共有を外すにはBashで clouddrive unmount、PowerShellで Dismount-CloudDrive を実行します。外しても共有自体は消えませんが、リソースグループやストレージアカウントを手動で削除すると $HOME のイメージも消え、元に戻せません。

導入済みツールのバージョン確認：公式一覧・イメージ定義・実行環境の違い

Cloud Shellには、Azure CLI・Azure PowerShell・AzCopy・Bicep CLI・kubectl・Helm・Terraform・Ansible・Git・GitHub CLI・MySQL／PostgreSQLクライアント・sqlcmdなどが最初から入っており、公式は「毎月更新される」としています（Microsoft Learn「Azure Cloud Shell の機能」）。

ただし、同じ機能ページの「プログラミング言語」欄は .NET 7.0・PowerShell 7.4・Python 3.9 という表記のままです。Cloud Shellのコンテナイメージを定義しているMicrosoftの公開リポジトリ（github.com/Azure/CloudShell）を2026年10月28日に確認すると、イメージ定義上の構成は次のとおりで、一覧とは食い違っています。

主要ツールの版は、機能ページではなくCloud Shellのリリースノートに月ごとに載ります。2026年9月の更新では、Azure CLI 2.90.0、Azure PowerShell 16.3.0、Azure Developer CLI 1.32.0、Bicep CLI 0.46.1、Terraform 1.16.0、kubectl 1.37.0、Node.js 24.18.1に上がりました。Python 3.12.9への更新は2025年4月の項にあります。Azure CLIとAzure PowerShellは破壊的変更を含む版にも自動で上がるため、Cloud Shellで動かしている手順書やスクリプトは、月が変わったら一度動作を確かめておくと安全です。

一方、リポジトリのREADMEには「ここでの変更がすべてのリージョンのCloud Shellに反映されるまで最大3〜4週間かかることがある」とあります。機能ページの表もリリースノートも、今あなたが開いているCloud Shellの版を正確に示すとは限りません。スクリプトが特定の版に依存するなら、シェルの中で確かめるのが確実です。

az version
python3 --version
dotnet --version
node --version
terraform version
kubectl version --client
pip3 list

PowerShellでは Get-Module -ListAvailable で導入済みモジュールを確認できます。なお、Azure CLIとは別に、アプリのひな型からデプロイまでをまとめて扱うAzure Developer CLI（azd）という上位のツールもあります。

自分でツールを追加できる範囲

Cloud Shellのユーザーは特権を持たない一般アカウントで、sudo や管理者権限が要るコマンドは実行できません。追加できるのはroot権限が要らないもの、たとえばPythonモジュール（pip install --user）、npmパッケージ、PowerShellモジュール、wget で取得して ~/bin に置く単体バイナリなどです。これらが次回も残るのは、永続ストレージを使っていて $HOME 配下に入れた場合だけです。tdnf install でOSパッケージを足すことはできません。

Cloud Shellが向かない作業と制限

Cloud Shellは対話的な管理作業のためのサービスで、汎用の計算環境ではありません。公式FAQにある制限を押さえておくと、どこまで任せてよいか判断できます（Microsoft Learn「Azure Cloud Shell のよく寄せられる質問とトラブルシューティング」）。

無操作20分のタイムアウトと長時間ジョブ

キーボードやマウスの操作が20分途絶えると、セッションは警告なしに終了し、実行中のコマンドも止まります。tmux や nohup で裏に回しても、セッションのマシン自体が回収されるので逃げ道になりません。数十分を超えるデプロイやデータ移行は、Cloud Shellで走らせ続けるのではなく、Azure PipelinesのYAMLで組むCI/CDやVM、Azure Automationに移すのが筋です。

公式FAQは、CPUを大量に使う利用（例として大きなAzCopyジョブ）が不正利用の検知に引っかかり、テナント全体でCloud Shellが無効化される場合があるとも書いています。このときは TenantDisabled エラーが出て、サポートへの依頼でしか戻せません。テラバイト級のコピーはVMやAzure Data Factoryから流すほうが安全です。

テナントあたり同時20ユーザーの上限

Cloud Shellは1つのテナント（Microsoft Entraのディレクトリ）につき同時20ユーザーまでで、超えると「Tenant User Over Quota」エラーになります。研修やハンズオンで受講者全員が同じテナントのCloud Shellを開くと、この上限に当たります。20人を超える研修では、開催日より前にサポートへ上限引き上げを依頼しておきます。

プライベートリソースへの接続制限と仮想ネットワーク分離

標準のCloud ShellはMicrosoft側のネットワークで動くため、プライベートIPしか持たないVMやプライベートエンドポイント経由のサービスには接続できません。届かせるには、Cloud Shellを自分の仮想ネットワークへ展開する「仮想ネットワーク分離」を構成します。この構成ではAzure Relay（有料）を使い、Cloud Shellを開いている管理者1人につき1つのハイブリッド接続が使われます。標準より起動が遅くなる点も公式に明記されています（Microsoft Learn「Azure 仮想ネットワークで Cloud Shell を使用する」）。

やりたいことがVMへのSSH・RDPだけなら、Cloud Shellを仮想ネットワークに入れるより、Azure Bastion（踏み台サーバーのマネージド代替）を使うほうが構成は単純です。Cloud Shellの仮想ネットワーク展開が向くのは、CLIやPowerShellのリモート実行をプライベートネットワーク内で常用したい場合です。社内のAzure環境の設計から相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）の支援も行っています。

Cloud Shellが起動しないときのエラー別の対処

初回起動やストレージ作成では、権限・ポリシー・ネットワークに加え、テナントの同時利用上限や利用停止も確認します。公式FAQに載っている主なエラーと対処を整理します。

「Failed to connect terminal」は、社内プロキシやファイアウォールが *.console.azure.com と *.servicebus.windows.net へのWebSocket通信を通していないときに出ます。社内ネットワークでは開けないのに自宅では開ける、という場合はこれを疑います。プライベートDNSを使う社内ネットワークで端末を要求できない場合は、ブラウザの開発者ツールで接続先のAzure Relayのホスト名を調べ、プライベートDNSゾーンにAレコードを足す手順が公式に示されています。

逆に管理者としてCloud Shellを使わせたくない場合は、ネットワークで *.console.azure.com への通信を止めます。ただし公式は、この方法ではVS Code for the WebやWindows Terminalからの入口までは塞げず、テナント全体で止めるにはサポートへの依頼が必要としています。ストレージ作成だけを禁じたいなら、前述の ms-resource-usage:azure-cloud-shell タグを条件にしたAzure Policyで制御できます。

よくある質問

Azure Cloud Shellの利用に料金はかかりますか？

シェルの実行環境は無料です。Cloud Shellの利用に伴って発生するのは、ファイルを残すためにマウントするAzure Files共有のストレージ料金と、仮想ネットワーク内に展開した場合のネットワーク料金です。標準のエフェメラルセッション自体は無料です。ただし、Cloud Shellから作成したVMなどのAzureリソースは、そのサービスの料金体系に従って課金されます。

Cloud Shellで作ったファイルが消えたのはなぜですか？

エフェメラルセッションでは、ウィンドウを閉じるか再起動した時点でファイルが削除されます。永続ストレージを使っていても、$HOME の外に置いたファイルは残りません。また無操作20分でセッションのマシンが回収されます。残したいファイルは、永続ストレージの $HOME/clouddrive に置き、ストレージブラウザーで保存を確認するか、ダウンロードして手元に保管してください。

BashとPowerShellはどちらを選べばよいですか？

Azure CLI中心でLinuxのコマンドに慣れているならBash、Azure PowerShellのコマンドレットやWindows Serverの運用に慣れているならPowerShellが向いています。どちらのシェルでもAzure CLIとAzure PowerShellの両方が使え、ツールバーからいつでも切り替えられるので、最初の選択で困ることはありません。

AWS CloudShellとは何が違いますか？

どちらも無料のブラウザシェルですが、ストレージの扱いが違います。AWS CloudShellの標準環境はリージョンごとに1GBの永続ストレージが無料で付き、そのリージョンで最後のセッションを終了してから120日間利用しないとデータが削除されます。ただし、VPC環境には永続ストレージがありません。Azure Cloud Shellは永続化に自分のAzure Files共有を使い（公式概要では5GBのファイル共有）、ストレージ料金は自分持ちです。無操作時のタイムアウトはAWSが20〜30分、Azureが20分です（AWS CloudShell「Service quotas and restrictions」）。

ローカルにAzure CLIをインストールする必要はありますか？

Cloud Shellで作業する分には不要です。ただし、操作せずに長時間実行する処理やCI/CDは、ローカル環境やパイプラインなどで実行します。操作手段にはAzure CLIのほか、Azure PowerShellなども選べます。日常の確認作業はCloud Shell、継続的な開発と自動化はローカルとパイプライン、と分けるのが現実的です。

関連記事

• Azure Developer CLI（azd）とは？Azure CLIとの違い・インストールとazd upの使い方
• Azure Bicepとは？インストールからbicep build・デプロイまでの実務手順
• TerraformでAzureを構築する手順｜azurerm 5系の認証とbackend設計
• Azure Bastionとは？踏み台サーバーのマネージド代替・4つのSKUと接続方式・料金を実装者目線で解説
• Azure Pipelinesの使い方｜YAMLの書き方とCI/CDパイプライン作成手順【2026年10月】