Amazon AppStreamとは：WorkSpaces Applicationsへの改名とフリート別の料金・構築手順

Amazon AppStream 2.0は、Windowsなどのデスクトップアプリを AWS 上で動かし、その画面だけを利用者のブラウザや専用クライアントへ転送するアプリケーションストリーミングのサービスです。2025年11月6日に名称が Amazon WorkSpaces Applications に変わりましたが、APIやCLIのコマンド名は appstream のまま残っています。この記事では、仕組みと改名の影響、Always-On・On-Demand・Elasticの3つのフリートの違い、Amazon WorkSpacesとの使い分け、東京リージョンの料金の実額、AWS CLIでの構築手順までを、2026年10月時点の公式ドキュメントと料金データに沿って説明します。

まとめ：Amazon AppStream（現WorkSpaces Applications）を選ぶ条件の結論

AppStreamが向くのは、特定の業務アプリを社外の端末や委託先へ配りたいが、データは端末に残したくない場面です。デスクトップ全体を1人1台で貸すAmazon WorkSpacesとは目的が異なり、セッションが終わるとインスタンスごと破棄される非永続の仕組みが前提になります。

費用を大きく左右するのはフリートの種類です。待ち時間ゼロのAlways-Onは利用者がいなくても課金され、On-Demandは起動に1〜2分かかる代わりに未使用時は停止中料金で済みます。東京リージョンのWindows標準インスタンス（stream.standard.medium）は1時間0.12ドル、停止中は0.029ドルで、これにWindows利用者1人あたり月4.19ドルが加わります。

見落としやすい出費は2つあります。夜間も台数を減らさずにOn-Demandのフリートを置くと停止中料金が積み上がる点と、Officeを含むイメージは使わない人にも月額ライセンス料がかかる点です。常時フル稼働のデスクトップ利用や、ローカルに作業データを残したい業務なら、AppStreamは選びません。

AppStreamの配信の仕組みとWorkSpaces Applicationsへの改名

AppStreamは2013年にゲーム配信寄りのSDKとして始まり、2016年に汎用のデスクトップアプリ配信へ作り直されたのが「2.0」です。現在の公式ドキュメントはWhat Is Amazon WorkSpaces Applications?という題名になっており、検索では旧名と新名の両方が使われています。

アプリを画面転送で届ける仕組みと端末にデータを残さない非永続性

アプリ本体はAWS側のストリーミングインスタンス（EC2）で動き、利用者の端末には画面と音声だけが送られます。キーボードとマウスの入力が逆向きに流れるので、端末側にアプリをインストールする必要はありません。Windowsの利用者はHTML5対応ブラウザか専用クライアントから接続できます。

インスタンスは1人のユーザーに割り当てられ、セッションが終わるとEC2ごと終了します。各インスタンスにはCドライブ用の200GBのボリュームがありますが、公式のインスタンスファミリー解説のとおり、セッション後すぐに削除されます。保存が要るファイルの退避先は、後述するホームフォルダなどの永続ストレージです。

2025年11月6日の改名で変わった表示名と変わらないAPI・CLI・料金

改名で変わったのは、コンソールやクライアントアプリの表示名、製品ページの置き場所です。旧URLの aws.amazon.com/appstream2/ はWorkSpaces applicationsの製品ページへ転送されます。

変わっていないのは、APIとCLI、サービスエンドポイント、IAMのアクション名（appstream:CreateStreamingURL など）、料金体系です。既存のスクリプトやIaCのコードは書き換えずにそのまま動きます。社内手順書を直す場合も、コマンドは aws appstream のまま、画面の名称だけを新名に置き換えれば足ります。

イメージビルダー・イメージ・フリート・スタックの役割と組み立て順

構築の部品は4つで、Key Conceptsのページに定義があります。組み立てる順番どおりに並べると次のとおりです。

1. イメージビルダー：アプリをインストールして動作を確かめる作業用の仮想マシン
2. イメージ：イメージビルダーから作る配布用の原本。作成後は変更できず、アプリ更新のたびに新しいイメージを作る
3. フリート：イメージから起動するストリーミングインスタンスの集まり。インスタンスタイプと台数の決め方をここで指定する
4. スタック：フリートに、利用者のアクセス方針と保存先の設定を束ねた公開単位

実務で手間がかかるのは2番目です。イメージは不変なので、アプリのパッチを当てるたびにイメージを作り直し、フリートの参照先を差し替える運用が発生します。月1回の更新でも、検証と切り替えに半日程度の作業枠を見込んでおくと計画が崩れません。

Always-On・On-Demand・Elasticの3フリートの違いと選ぶ基準

フリートの種類は作成時に決め、後から変更できません。公式のフリートタイプ解説をもとに、選ぶ基準を整理します。

起動待ち1〜2分を許せるかで決まるAlways-OnとOn-Demand

Always-Onは、インスタンスを常に起動しておく方式です。利用者はアプリを選んだ瞬間に使い始められますが、誰も接続していない時間も稼働料金がかかります。On-Demandは、割り当て前のインスタンスを停止状態で待たせ、接続時に起動する方式です。アプリが開くまで1〜2分待たされる代わりに、待機中は安い停止中料金で済みます。

どちらも台数はオートスケーリングのルールで管理します。ルールには利用率に応じたものと、曜日や時刻で台数を変えるスケジュール型の2種類です。窓口業務のように「開いた瞬間に使えないと困る」用途はAlways-On、社内の業務アプリのように始業時に一度待てば済む用途はOn-Demandが合います。

アプリブロックで配るElasticフリートと最低15分の秒課金

Elasticは、インスタンスの確保をAWSに任せる方式です。イメージの代わりに、アプリのファイルをS3に置いたアプリブロックを使い、接続のたびにインスタンスへ取り込んでから起動します。台数の予測もスケーリングルールも不要で、課金はセッション時間の秒単位（最低15分）です。

選べるOSとインスタンスには明確な制約があります。CLIリファレンス上、Elasticで選べるのは stream.standard 系のサイズだけで、OSは Windows Server 2019、Amazon Linux 2、Ubuntu Pro 24.04 に限られます。さらに、異なるアベイラビリティゾーンのサブネットを2つ以上指定することが必須です。研修やソフトの体験版のように、利用が月に数回の山しかない用途で使う方式です。

Windows限定のマルチセッションで1台に複数ユーザーを載せる条件

マルチセッションは、1台のインスタンスに複数の利用者のセッションを同居させる機能です。対象はWindowsのAlways-OnとOn-Demandのみで、ElasticとLinuxでは使えません。インスタンス料金は同時接続数にかかわらず稼働時間で決まるため、軽い業務アプリなら1人あたりの単価を下げられます。

代わりにユーザー課金はシングルセッションの月4.19ドルから6.42ドルに上がります。1台に何人載せられるかはアプリのメモリ消費で決まるので、事前に負荷を測ってから --max-sessions-per-instance を決めてください。

Amazon WorkSpacesとの違いとアプリ配信か丸ごとデスクトップかの分岐

同じWorkSpacesブランドに入ったことで、Amazon WorkSpaces（デスクトップ型）との違いが分かりにくくなりました。WorkSpaces側の構成や料金はAmazon WorkSpacesの仕組み・料金・Personal/Pools/Coreの違いで詳しく扱っているので、ここでは分岐点に絞ります。

配信単位・永続性・認証・課金の4軸で並べたWorkSpacesとの比較

表のAppStreamは現Amazon WorkSpaces Applications、WorkSpacesはAmazon WorkSpaces（Personal）を指します。判断の起点は「利用者が自分の環境を育てるか」です。ブラウザのブックマークや開発ツールの設定を日々積み上げる社員にはWorkSpacesを、決まったアプリを決まった手順で使うだけの利用者にはAppStreamを割り当てます。同じ会社で両方を併用する構成も珍しくありません。VPNやリモートデスクトップとの違いを先に押さえたい場合は、リモートデスクトップの仕組みとVPN・VDIとの違いが前提の整理になります。

東京リージョンの料金と月額を左右するユーザー課金・停止中インスタンス料

料金は公式の料金ページで公開されていますが、単価の例は米国東部が中心です。ここでは東京リージョンの単価を、AWSのPrice List API（2026年10月14日公開版）から取り出して整理しました。

Windows標準インスタンス3サイズとElastic・停止中の東京単価

表のstream.standard.small・stream.standard.medium・stream.standard.largeの通常料金はAlways-On・On-Demandが対象です。medium（Elastic）はstream.standard.medium（Elastic）の単価を示しています。Windowsの利用者課金は、月に1回でも接続すれば日割りなしで全額かかります。Rocky LinuxやRHEL、自社ライセンスを持ち込むBYOLにはこの利用者課金がありません。Linuxのインスタンスは秒単位（最低15分）で、Windowsは1時間単位という違いもあります。

20人が営業時間だけ業務アプリを使う場合の試算と停止中料金の落とし穴

社員20人が1日8時間・月20日、stream.standard.mediumのOn-Demandで業務アプリを使う場合を、1か月720時間で計算します。

• 稼働料金：20人×160時間×0.12ドル＝384.00ドル
• 利用者課金：20人×4.19ドル＝83.80ドル
• 夜間も20台を停止状態で置いた場合の停止中料金：（20台×720時間−3,200時間）×0.029ドル＝324.80ドル
• 同じ20台をAlways-Onで24時間置いた場合の稼働料金：20台×720時間×0.12ドル＝1,728.00ドル

On-Demandでも台数を減らさずに置けば月792.60ドルになり、スケジュール型のスケーリングで業務時間外を0台にすれば467.80ドルまで下がります。差の324.80ドルは、稼働料金の8割を超える額です。On-Demandを選んだら、スケジュールの設定までを構築作業に含めてください。Elastic（0.18ドル）なら同じ使い方で576.00ドルに利用者課金を足した659.80ドルで、台数管理の手間と引き換えにどちらを取るかの比較になります。

Office同梱イメージは使わない利用者にも月額ライセンス料がかかる

AppStreamでは、Microsoft Office・Visio・ProjectのLTSC 2021／2024をライセンス込みでイメージに入れられます。東京の月額は Office LTSC Professional Plus が1人21.43ドル、Standard が15.70ドルです。

落とし穴は、アプリを起動しなくても課金される点です。License Includedの公式解説によれば、ライセンス込みのアプリを含むイメージのフリートを使った利用者は、そのアプリを起動したかどうかに関係なく毎月課金されます。上の20人の例で全員にProfessional Plusが付くと428.60ドルが加わり、インスタンスの稼働料金を上回ります。Officeを使う人と使わない人は、イメージとフリートを分けて配るのが基本です。

Price List APIで東京の単価を取り直すPythonスクリプト

単価は改定されるので、見積もりの前に取り直す手順を残しておくと安全です。次のコードは認証不要のPrice List APIから東京リージョンのオファーを取得し、上の表に使った項目を表示します。Python 3の標準ライブラリだけで動きます。

import json
import urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"


def get(url):
    with urllib.request.urlopen(url, timeout=120) as res:
        return json.load(res)


idx = get(BASE + "/offers/v1.0/aws/AmazonAppStream/current/region_index.json")
offer = get(BASE + idx["regions"]["ap-northeast-1"]["currentVersionUrl"])
print("version:", offer["version"])

targets = {
    "APN1-stream.standard.medium-fl",
    "APN1-stream.standard.medium-elfl",
    "APN1-StoppedInstance-fl",
    "APN1-Win-User",
    "APN1-Win-User-Multi-Session",
}
for sku, prod in offer["products"].items():
    attrs = prod["attributes"]
    if attrs.get("usagetype") not in targets:
        continue
    for term in offer["terms"]["OnDemand"].get(sku, {}).values():
        for dim in term["priceDimensions"].values():
            print(attrs["usagetype"], attrs.get("instanceFunction", "-"),
                  dim["pricePerUnit"]["USD"], dim["unit"])

2026年10月19日に実行した結果は、version 20261014222424、mediumのFleetとMultiSessionFleetが0.12、ElasticFleetが0.18、停止中が0.029、利用者課金が4.19と6.42でした。サイズを変えるときは targets の medium を small や large に置き換えます。

AWS CLIでフリートとスタックを作りストリーミングURLを発行する手順

ここでは、イメージビルダーで作成済みのイメージがある前提で、On-Demandフリートの作成から利用者向けURLの発行までをCLIでたどります。CLIそのものの導入とSSO認証はAWS CLIのOS別の導入手順とv2の設定を参照してください。コマンドの一覧はAWS CLIのappstreamリファレンスにあります。

ON_DEMANDフリートの作成からスタックとの関連付けまでのコマンド

# 1. On-Demandフリートを作成（イメージ名・サブネット・SGは自社の値に置き換える）
aws appstream create-fleet \
  --name sales-app-fleet \
  --image-name sales-app-image-202610 \
  --instance-type stream.standard.medium \
  --fleet-type ON_DEMAND \
  --compute-capacity DesiredInstances=2 \
  --vpc-config SubnetIds=subnet-aaaa1111,subnet-bbbb2222,SecurityGroupIds=sg-cccc3333 \
  --max-user-duration-in-seconds 28800 \
  --disconnect-timeout-in-seconds 900 \
  --idle-disconnect-timeout-in-seconds 900

# 2. ホームフォルダを有効にし、端末へのファイルダウンロードを禁止したスタックを作成
aws appstream create-stack \
  --name sales-app-stack \
  --storage-connectors ConnectorType=HOMEFOLDERS \
  --user-settings Action=FILE_DOWNLOAD,Permission=DISABLED

# 3. スタックとフリートを関連付けてフリートを起動
aws appstream associate-fleet --stack-name sales-app-stack --fleet-name sales-app-fleet
aws appstream start-fleet --name sales-app-fleet

# 4. 状態がRUNNINGになったことを確認
aws appstream describe-fleets --names sales-app-fleet --query "Fleets[0].State"

最大セッション時間は8時間（28800秒）、切断後の再接続待ちと無操作での切断はそれぞれ15分にしています。CLIリファレンス上、切断後の待ち時間に指定できる範囲は60〜36000秒です。FILE_DOWNLOAD を無効にすると、作業データを端末へ持ち出せなくなり、委託先への配布で求められる情報管理の条件を満たしやすくなります。

create-streaming-urlの既定60秒の有効期限と自社画面への組み込み

ユーザー登録なしで接続を試すなら、一時的なURLを発行する create-streaming-url が手軽です。

aws appstream create-streaming-url \
  --stack-name sales-app-stack \
  --fleet-name sales-app-fleet \
  --user-id partner-user-001 \
  --validity 300

--validity の既定値は60秒、上限は604800秒（7日）です。応答の StreamingURL を開くとセッションが始まります。自社のポータルにログインした利用者へ、このAPIをサーバー側で呼んで短命のURLを渡す構成にすれば、AppStream側にユーザーを登録せずに済みます。URLは発行した時点で誰でも開けるので、有効期限は数分に絞り、ログやチャットに残さない運用にしてください。

ユーザープールとSAML 2.0連携、ホームフォルダによる保存先の設計

利用者の認証は3通りです。数十人規模の検証ならメールアドレスで招待するユーザープール、本番では既存のIdPと結ぶSAML 2.0連携、自社ポータルがあるなら前項のストリーミングURL方式を選びます。SAMLの認証フローやIdPとSPの役割はSAMLの認証フローとOAuth・OIDCとの使い分けで整理しています。

保存先はホームフォルダの公式解説のとおり、ホームフォルダ（自社アカウントのS3バケット）、Google Drive、OneDrive for Business、SMBの共有フォルダから選べます。ホームフォルダの中身はS3のマネージドキーで暗号化され、次回のセッションでも同じファイルを参照可能です。バケットのライフサイクルや権限の考え方はAmazon S3のストレージクラスと料金の解説が参考になります。

AIエージェント向けMCPアクセスでデスクトップアプリを操作させる仕組み

2026年10月時点の公式ドキュメントには、AIエージェントにストリーミングセッションを操作させる機能が加わっています。APIが無い古い業務アプリを、人の代わりにエージェントが画面越しに操作する使い方です。

agentaccess-mcpの接続先・IAM権限とセッションの制約

エージェントアクセスの入門手順では、スタック作成時にAIエージェントのアクセスを有効にし、通常の CreateStreamingURL で発行したURLをエージェントへ渡します。エージェントは agentaccess-mcp.<リージョン>.api.aws/mcp のエンドポイントへSigV4署名つきで接続し、クリック・文字入力・スクリーンショット取得・アプリ起動などのツールを呼びます。IAMでは agentaccess-mcp:* と appstream:CreateStreamingURL などの権限が必要です。

押さえておく制約は、1つのセッションに接続できるエージェントが1つだけという点です。並列で動かすならエージェントごとにセッションを分けるため、インスタンス時間がその数だけ増えます。料金ページでは東京のMCPセッションが1時間0.05ドル（毎月10時間まで無料）と示されており、ストリーミングの稼働料金とは別の費用です。操作の記録はCloudTrailに、指標はCloudWatchに残るので、誤操作の追跡手段は最初から用意されています。

Amazon AppStreamを採用すべき条件と見送って別方式に寄せる場面

ここまでの仕組みと費用を踏まえ、採用と見送りの線を条件つきで示します。

採用が向く条件：社外配布・端末に残さない業務・利用時間の偏り

次の3つのうち2つ以上に当てはまるなら、AppStreamを第一候補にします。1つ目は、協力会社や顧客など自社で端末を管理できない相手にアプリを渡す場合です。2つ目の条件には、個人情報や設計データを端末に残せず、ダウンロードとクリップボードを止めたい場合が当てはまります。3つ目は、利用が営業時間や月末など特定の時間帯に偏り、24時間の常時稼働が要らない場合です。

とくに、Windowsでしか動かない古い業務アプリを社外へ公開したい案件では、アプリを改修せずに配れる点が効きます。フリートのスケジュール設定、SAML連携、ホームフォルダの権限設計まで含めて構築を任せたい場合は、AWS・Google Cloud・Azureのインフラ構築でご相談いただけます。

採用を見送る条件：常時フル稼働・Officeの一部利用・Web化済みアプリ

社員が毎日8時間以上、自分用に設定を積み上げたデスクトップで働くなら、非永続のAppStreamは毎回の環境再現が負担になります。この場合はAmazon WorkSpacesを選びます。Officeを使う人が一部だけなのに全員を同じイメージに載せる構成も、前述のとおりライセンス料が膨らむので採りません。

配りたいアプリがすでにブラウザで動くWebアプリなら、画面転送を挟む理由がありません。ブラウザの中で既存アプリを配る別方式としてはCameyoの仕組みとVDIとの違いもあります。AppStreamは「インストール型のアプリを、手元に残さず、使う時間だけ配る」ときに選ぶ道具で、それ以外の場面では他の方式のほうが安く単純です。

よくある質問

Amazon AppStreamの検討時によく出る質問に、2026年10月時点の公式情報をもとに答えます。

AppStream 2.0は終了したのですか？

終了していません。2025年11月6日にAmazon WorkSpaces Applicationsへ名称が変わっただけで、既存のフリートやスタックは中断なく動き続けています。APIとCLIのコマンド名は appstream のままで、料金体系も改名前と同じです。公式ドキュメントのURLも appstream2 を含む形で残っているため、旧名で書かれた手順書のコマンドはそのまま使えます。名称を直す必要があるのは、画面表示を説明している箇所だけです。

AppStreamとWorkSpacesはどちらが安いですか？

利用時間で逆転します。AppStreamは使った時間とWindows利用者1人あたり月4.19ドルの組み合わせなので、営業時間だけ、または月に数日しか使わない利用者ほど有利です。WorkSpacesは1人1台の月額固定を選べるため、毎日フルタイムで使う社員は月額固定のほうが読みやすくなります。AppStreamのOn-Demandで夜間に台数を減らさないと停止中料金が加わり、差が縮む点にも注意が要ります。

Linuxのアプリも配信できますか？

Linuxのアプリも配信の対象です。Always-OnとOn-DemandではRocky Linux 8とRHEL 8、ElasticではAmazon Linux 2とUbuntu Pro 24.04が選べます。Linuxのインスタンスは秒単位（最低15分）の課金で、Windowsのような利用者ごとの月額がかからないため、利用者数が多く1人あたりの時間が短い用途では費用を抑えやすくなります。ただしマルチセッションはWindows限定で、Linuxの割り当ては1台1セッションです。

GPUが必要なCADや3Dソフトも使えますか？

GPUが必要なCADや3Dソフトも配信の対象です。グラフィックス用のインスタンスファミリーとして、NVIDIA T4を積むG4dn、A10GのG5、G6系、L40SのG6e、RTX PRO 4500 BlackwellのG7などが用意されています。GPU付きのインスタンスは標準のものより時間単価が大きく上がるため、Always-Onで常時起動すると費用が膨らみます。設計部門の利用時間を測り、On-Demandとスケジュール型のスケーリングで稼働時間を絞るのが基本です。

Active Directoryは必須ですか？

必須ではありません。ユーザープールかSAML 2.0連携、ストリーミングURL方式のいずれでも利用者を認証できます。Active Directoryが要るのは、ストリーミングインスタンスをドメインに参加させ、グループポリシーや社内のファイルサーバーをそのまま使いたい場合です。その場合はAWS Managed Microsoft ADなどを組み合わせます。ADの選択肢はAWS Directory Serviceの3方式の違いで比較しています。

関連記事

• Amazon WorkSpacesとは｜AWSの仮想デスクトップ(DaaS)の仕組み・料金・Personal/Pools/Coreの違いと採用判断：デスクトップ全体を1人1台で配る場合の比較先
• リモートデスクトップとは？仕組み・VPN/VDIとの違いと設定手順・企業導入の判断【2026年版】：方式の全体像から検討を始める場合に
• AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説：管理者側のAWSアカウントへのアクセス設計
• AWS Directory Serviceとは：Managed Microsoft AD・AD Connector・Simple ADの違いと東京の料金【2026年版】：ドメイン参加型のフリートを組む場合の前提
• Cameyo（カメヨ）とは？Cameyo by Googleの仕組み・料金・使い方・導入手順とVDIとの違い：ブラウザでアプリを配る別方式との比較