Appium Desktopは終了｜Appium 3時代のInspector移行とモバイルテスト自動化

Appiumは、iOS・Androidのネイティブアプリを実機やシミュレータ上で操作し、UIテストを自動実行するオープンソースのフレームワークです。1本のテストコードで両OSを動かせる点が最大の特徴で、W3C WebDriverプロトコルに準拠しているためSeleniumの資産とクライアントライブラリをそのまま流用できます。ただし2026年7月時点の情報環境は厄介で、日本語の解説記事の多くがAppium 1系のまま止まっています。とくに「Appium Desktop」をインストールする手順は、いま実行してはいけない操作です。この記事では、Appium Desktopが何に置き換わったのか、2025年8月に出たAppium 3で何が壊れるのかを一次情報で確認しながら、環境構築からテスト実行までを整理します。

まとめ：Appium Desktopは終了、いまはCLIサーバ＋Appium Inspector

先に結論を置きます。検索してたどり着く古い記事との差分は、次の5点に集約されます。

• Appium Desktop（GUI版サーバ）は使ってはいけない：2022年5月のv1.22.3-4を最後に開発停止、リポジトリはアーカイブ済み。Appium 2以降と互換性がなく、公式が「非推奨化のあとにリモートコード実行を許す脆弱性が見つかったが修正予定はない」と明言している。
• 置き換え先は2つに分割された：サーバはnpm install -g appiumで入れるCLI版、画面要素を調べるGUIは独立アプリのAppium Inspector（最新v2026.5.1）。
• 現行はAppium 3系：3.0.0が2025年8月18日リリース、最新は3.5.2（2026年6月18日）。Node.js 20.19以上が必須で、Node 16世代の手順書はそのまま失敗する。
• Seleniumとの関係：AppiumはW3C WebDriverサーバの一種。Selenium Grid 4のrelay機能で同じグリッドに載せられる。違いは対象が「ブラウザ」か「ネイティブアプリ」かという一点に尽きる。
• 向かない場面：React Native単体のプロジェクト、テスト実行速度を最優先する現場、Windowsデスクトップアプリ主体の自動化。それぞれDetox・Maestro・NovaWindowsのほうが素直に収まる。

バージョンとドライバは月次で動きます。着手時は必ず公式ドキュメント（appium.io）で最新の要件を確認してください。

Appium Desktop終了後の移行先

「appium desktop」で検索して出てくるインストール手順は、ほぼすべて2022年以前のものです。いまダウンロードしてはいけません。

Appium Desktopのアーカイブ経緯と残存リスク

Appium Desktopは、Appiumサーバの起動GUIと要素インスペクタを1つのデスクトップアプリにまとめたものでした。最終リリースはv1.22.3-4（2022年5月15日）、最後のコミットは2023年4月、リポジトリは現在アーカイブ状態です。公式READMEは冒頭に[DEPRECATED]と掲げ、二段構えで警告しています。ひとつはAppium 2.0以降と互換性がないためメンテナンスを終了したこと。もうひとつは、非推奨化された後に開いたポートがインターネットへ露出しているとリモートコード実行を許しうる脆弱性が発見され、修正する予定がないことです。社内の検証端末が同じネットワークに載っている環境では、これは実害のあるリスクになります。「動くから使い続ける」で済ませてよい種類の非推奨ではありません。

Appium Inspectorの入手経路と選択基準

Appium Desktopに同梱されていたインスペクタは、独立したプロダクトAppium Inspectorとして開発が続いています（最新v2026.5.1／2026年5月4日）。入手経路は3つありますが、選択は実質2択です。

デスクトップアプリはmacOS向けの.dmg、Windows向けの.exe、Linux向けの.AppImageがGitHub Releasesで配布されています。署名・notarizeがされていないため初回起動時に警告が出ます。macOSでは xattr -cr "/Applications/Appium Inspector.app" で回避できます。Homebrew経由の配布（brew install --cask appium-inspector）はコミュニティ管理でありAppiumチームの保守対象ではなく、2026年9月1日に無効化予定と公式が告知しています。これから手順書を書くなら採用しないでください。

プラグイン版はAppium 3で appium plugin install inspector の一行で導入できます（Appium 2で使う場合は最終互換版の appium plugin install --source=npm [email protected] を指定）。サーバ自体がInspectorをホストするため、ブラウザだけで要素ツリーを見られます。

Appium Inspectorで要素を特定する最小手順

Inspectorは「起動中のAppiumサーバに接続し、セッションを張って画面のUIツリーを見る」ツールです。サーバを別途起動しておく必要があります。

# 端末1: サーバをプラグイン付きで起動
appium --use-plugins=inspector

# 端末2ではなくブラウザで開く
# http://127.0.0.1:4723/inspector

画面ではRemote Hostに 127.0.0.1、Remote Portに 4723 を入力し、右側のペインにcapabilities（platformName、appium:automationName、appium:deviceName など）をJSONで貼り付けてStart Sessionを押します。接続に成功すると端末のスクリーンショットとUIツリーが並んで表示され、要素をクリックするとid・XPath・アクセシビリティIDが右下に出ます。ここで得たロケータをそのままテストコードへ移すのが基本の流れです。デスクトップアプリ版でも入力項目と操作は同じです。

Appiumの仕組み：W3C WebDriverサーバとドライバの分離

Appiumを「Androidを操作するツール」と理解すると、ドライバ周りのエラーが読めなくなります。実体は命令を中継するHTTPサーバです。

クライアントから端末までの4層

テストコード（クライアント）はHTTPでAppiumサーバに命令を送り、サーバは指定されたドライバへ処理を委譲し、ドライバが各OS純正の自動化フレームワークを叩き、それが端末を動かします。Androidならappium-uiautomator2-driverがGoogleのUiAutomator2を、iOSならappium-xcuitest-driverがAppleのXCUITestを呼びます。つまりAppiumはEspressoやXCUITestの競合ではなく、それらを共通のプロトコルで包み直す層です。iOS側で実際に何が動いているのかはXCTestの基本解説を読むと具体像がつかめます。EspressoやXCUITestを直接使う場合と比べてAppiumの実行が重くなるのは、この中継が1操作ごとにHTTP往復を挟む構造に由来します。

Seleniumとの違い：共有するプロトコルと分かれる操作対象

両者はプロトコルを共有しています。AppiumはW3C WebDriverプロトコルの上に構築されたサーバで、Javaクライアント（io.appium:java-client）はSeleniumのJavaクライアントを継承しています。Seleniumを使ったWebアプリのテスト自動化を経験していれば、driver.findElement() の書き味はそのままです。違いは操作対象がブラウザのDOMかネイティブアプリのUIツリーか、という点に絞られます。既存のSelenium Grid 4を持っているなら、relay機能でノードのTOMLに次のように書けば、同一グリッドからモバイル端末へリクエストをリレーできます。

[relay]
url = "http://localhost:4723"
status-endpoint = "/status"
configs = [
  "1", '{"browserName": "chrome", "platformName": "Android", "appium:platformVersion": "14"}'
]

Appium 3の環境構築：Node 20.19以上とドライバの個別導入

Appium 2以降、サーバ本体とドライバは分離されました。サーバを入れただけでは何も自動化できません。

サーバの導入と起動

公式がサポートするインストール手段はnpmのみです。要求Nodeバージョンは ^20.19.0 || ^22.12.0 || >=24.0.0、npmは10以上。Appium 2の要件はNode 14.17.0以上だったため、ここが古い記事との最大の非互換になります。Node 16や18で npm i -g appium しても弾かれます。

# Node 20.19+ が入っていることを確認
node -v

# Appium サーバ本体（2026年7月時点の最新は 3.5.2）
npm install -g appium

# 起動。既定で http://127.0.0.1:4723/ を listen する
appium

ドライバのインストールと事前診断

操作したいプラットフォームのドライバを個別に追加します。公式ドライバは名前だけで指定でき、コミュニティ製は --source=npm を付けます。

# Android（UiAutomator2、2026-07時点 8.1.0）
appium driver install uiautomator2

# iOS（XCUITest、11.17.6）
appium driver install xcuitest

# Flutter アプリはコミュニティ製ドライバ
appium driver install --source=npm appium-flutter-driver

# 導入済みドライバの一覧と、環境の不足チェック
appium driver list --installed
appium driver doctor uiautomator2

appium driver doctor は、Android SDKのパスやXcodeのコマンドラインツールなど不足している前提条件を列挙してくれます。環境構築でつまずいたら、推測でパスを直す前にこれを回してください。なおドライバのメジャー版はAppium 3に追従しており、UiAutomator2は5.0.0以降、XCUITestは10.0.0以降がAppium 3専用です（package.jsonのpeerDependenciesがappium@^3.0.0-rc.2を要求します）。Appium 2のまま最新ドライバを入れると弾かれます。

Windowsアプリを自動化する場合の注意

AppiumはWindowsデスクトップアプリも操作できますが、ここは事情が複雑です。appium-windows-driver（最新6.0.4）は、実際の操作をMicrosoftのWinAppDriverに委譲するプロキシです。そのWinAppDriverは、最後の安定版がv1.2.1（2020年11月5日）で止まっています。Appium公式のREADMEも「WinAppDriverサーバは何年もMicrosoftによってメンテナンスされていない」と警告しています。リポジトリ自体はアーカイブされていませんが、実質的に更新は止まっていると見るべきです。ドライバv3.0.0以降はWinAppDriverを自動インストールしなくなったため、appium driver run windows install-wad で明示的に導入する必要があります。Appium公式READMEは代替としてNovaWindows Driver（appium driver install --source=npm appium-novawindows-driver）をドロップイン代替として挙げています。Windows自動化が主目的なら、最初からこちらを検討する価値があります。

テストコードの書き方：W3C capabilitiesとPythonの最小例

最初に詰まるのがcapabilitiesの書式です。Appium固有の項目には appium: 接頭辞が必須で、これはW3C WebDriver仕様の拡張capabilityとして定められた作法です。標準capabilityは platformName / browserName / browserVersion の3つだけで、それ以外はすべて拡張扱いになります。この接頭辞の必須化はAppium 2からの仕様で、Appium 1時代の接頭辞なしサンプルをコピーするとセッション作成の時点で失敗します。

Appium 3ではさらに、セッション作成リクエストのパラメータからJSONWP由来の desiredCapabilities / requiredCapabilities が削除され、W3C形式の capabilities のみが受理されるようになりました。クライアントライブラリを最新にしていれば意識せずに済みますが、自前でHTTPを組んでいる場合は影響します。

from appium import webdriver
from appium.webdriver.common.appiumby import AppiumBy
from appium.options.android import UiAutomator2Options

options = UiAutomator2Options()
options.platform_name = "Android"          # 標準 capability
options.automation_name = "UiAutomator2"   # 実体は appium:automationName
options.device_name = "emulator-5554"      # 実体は appium:deviceName
options.app = "/path/to/app-debug.apk"     # 実体は appium:app

driver = webdriver.Remote("http://127.0.0.1:4723", options=options)
el = driver.find_element(AppiumBy.ID, "com.example:id/login_button")
el.click()
driver.quit()

クライアントライブラリのOptionsクラスを使えば接頭辞は自動で付きますが、辞書で直接書く場合は {"platformName": "Android", "appium:automationName": "UiAutomator2"} のように自分で付けます。接頭辞の反復が煩わしければ、Appium固有項目を appium:options にまとめる書式も公式にあります。Pythonでテストを組み立てるなら、実行と検証の枠組みはpytestに載せるのが定石です。仕様を自然言語で書き下してから自動化したい場合は、CucumberのGherkin記法と組み合わせる構成も選べます。

Appium 2から3への移行で壊れる箇所

Appium 3の破壊的変更は「最小限」と公式が説明していますが、CIが黙って落ちる種類の変更が含まれます。移行前に確認すべきは次の4点です。

とくに刺さるのがセキュリティフラグのスコープ化です。--allow-insecure=adb_shell のように書いていたCI設定は、uiautomator2:adb_shell（全ドライバへ適用するなら *:adb_shell）へ書き換える必要があります。Appium 3はスコープなしの指定をエラーとして拒否するため、旧設定のままではサーバが起動せずCIがその場で落ちます。黙って無視されるわけではないので、原因の特定自体は難しくありません。セッション一覧の GET /appium/sessions は session_discovery フィーチャーフラグの有効化も必要です（Appium Inspectorの「Attach to Session」を使う場合はv2025.3.1以降が要ります）。このほか、アーカイブ展開ロジックがサーバからドライバ側へ移管されています。

モバイルテスト自動化ツールの選び方：Appium・Maestro・Detox

「モバイルアプリのテストを自動化したい」という出発点なら、Appiumが唯一の選択肢ではありません。判断軸は、対象プラットフォームの数と、テストを書く人が誰かの2つです。

Playwrightのモバイル対応範囲：ブラウザに限られる理由

先に誤解をひとつ潰しておきます。Web側で人気のPlaywrightは、モバイル対応と言われるものの実体はモバイルブラウザのエミュレーション（UA・viewport・タッチ操作の模倣）です。公式ドキュメントが明記しているAndroid対応も「実験的サポートであり、対象はAndroid上のChromeとWebView」に限られます。iOS/Androidのネイティブアプリを操作する用途では選択肢に入りません。

3ツールの住み分け

Appiumを選ぶべきでない場面

結論を言い切ります。React Nativeで作られたアプリの単体プロジェクトで、書き手がフロントエンドエンジニアなら、Appiumではなく Detox を選ぶべきです。Appiumはアプリの外側からUIツリーを見て操作するブラックボックス方式のため、アニメーションや非同期処理の完了を待てず、待機時間の調整（いわゆるflakyテスト対策）に工数が溶けます。Detoxはアプリ内部の処理完了と同期するグレーボックス方式で、この待機問題を構造的に回避します。同様に、QA担当が自分でシナリオを保守する体制ならMaestroです。YAMLで書けるため、プログラミングを本職としない担当者でも維持できます。逆にAppiumが確実に効くのは、iOSとAndroidに加えてWindowsアプリまで同じ枠組みで自動化したい場合や、既存のSelenium Gridとテストコード資産を流用したい場合です。テストケースの設計そのものを効率化したいなら、AIによるテストケース自動化と併読すると全体像がつかめます。

CI/CDへの組み込みとコンテナ実行の制約

Appiumサーバは単なるNodeプロセスなので、CIランナー上で起動してテストを流すだけです。GitHub Actionsでの自動テスト設定を土台にするなら、ジョブでNode 20系をセットアップし、ドライバを導入し、サーバをバックグラウンド起動する順序になります。

- uses: actions/setup-node@v4
  with:
    node-version: '20'
- run: npm install -g appium
- run: appium driver install uiautomator2
- run: appium --log-level error &
- run: pytest tests/

コンテナ化を考えるときに効いてくるのがiOSの制約です。XCUITestドライバはXcodeに依存するため、iOSのシミュレータ・実機テストはmacOSホストでしか動きません。LinuxコンテナにXcodeを入れることはできないので、Dockerで完結できるのは実質Android側だけです。そのAndroidも、コンテナ内でエミュレータを動かすにはホスト側でKVMが有効になっている必要があり、クラウドCIのランナーによっては使えません。iOS込みのCIを組むなら、macOSランナーを持つCIサービスか、実機クラウドの利用が現実解になります。

よくある質問

Appium Desktopはどこからダウンロードできますか？

ダウンロードすべきではありません。Appium Desktopは2022年5月のv1.22.3-4を最後に開発が終了し、GitHubリポジトリはアーカイブ済みです。Appium 2以降と互換性がないうえ、公式が「ポートが外部に露出しているとリモートコード実行を許しうる脆弱性があり、修正の予定はない」と明言しています。現在は、サーバを npm install -g appium のCLI版で、要素の調査をAppium Inspectorで行う構成に分かれています。

Appium InspectorとAppium Desktopは何が違うのですか？

Appium Desktopは「サーバ起動GUI＋インスペクタ」の一体型アプリでした。そのうちインスペクタ部分だけが独立して現在も開発が続いているのがAppium Inspectorです（最新v2026.5.1）。サーバ起動の機能はCLIの appium コマンドが担います。Appium 3なら appium plugin install inspector でサーバにInspectorを内蔵させ、ブラウザから http://127.0.0.1:4723/inspector で使うこともできます。

AppiumとSeleniumの違いは何ですか？

プロトコル（W3C WebDriver）は共通で、操作対象が違います。Seleniumはブラウザ、Appiumはネイティブアプリ・ハイブリッドアプリ・モバイルブラウザです。AppiumのクライアントはSeleniumクライアントを基盤に作られており、Selenium Grid 4のrelay機能を使えば同じグリッドからモバイル端末へ命令をリレーできます。Seleniumの経験があれば学習コストは低く済みます。

Appiumの学習に必要なスキルは何ですか？

プログラミング言語を1つ（Java・Python・Rubyなど公式クライアントのある言語）、UI要素を特定するためのロケータ（id・XPath・アクセシビリティID）の知識、そしてAndroid SDKまたはXcodeの基本操作です。加えてAppium 3ではNode.js 20.19以上の環境を用意する必要があります。テストコード自体はSeleniumとほぼ同じ書き方になるため、Web自動テストの経験があれば流用が効きます。

Appiumは無料で使えますか？

Appium本体・公式ドライバ・Appium InspectorはすべてApache 2.0ライセンスのオープンソースで、商用利用を含め無料です。費用が発生するのは、実機を多数用意する場合や、クラウド端末サービス（実機クラウド）を利用する場合です。

セッション作成に失敗するときは何を疑えばよいですか？

頻度の高い原因は3つです。ひとつはNode.jsのバージョン不足（Appium 3は20.19以上）。ひとつはcapabilitiesの appium: 接頭辞漏れ。もうひとつはドライバの未インストールで、appium driver list --installed で確認できます。環境側の不足は appium driver doctor uiautomator2 を実行すると、Android SDKのパスやJAVA_HOME、Xcodeのコマンドラインツールなど足りない前提条件が列挙されます。推測でパスを直す前に、まずこれを回してください。

関連記事

• Seleniumを活用したWebアプリケーションテストの実施方法
• XCTestとは何か：iOSアプリ開発における標準テストフレームワークの基本解説
• GitHub Actionsでビルド・自動テストを設定する方法｜CI/CDワークフローの作り方
• pytestの使い方・書き方を徹底解説｜インストールからfixture・パラメータ化まで
• AIによるテストケース自動化とは？次世代QAプロセスの概念や導入メリット・成功要因、有効事例まで徹底解説