候補に入れたいオープンソース RPA ツールと、その実行環境

一般的なオープンソース RPA の候補に挙がるツールの中には、デスクトップ環境のない Linux サーバーでは動かないものがいくつもあります。デスクトップのインターフェースを自動操作するため、グラフィカルセッションに依存しますが、そのようなサーバーには操作できるデスクトップセッションがありません。この性質だけでカテゴリは二つに分かれ、ボットをどこで動かせるかが決まります。

多くの人がおすすめのオープンソース RPA ツールを探すきっかけは、商用 RPA のライセンス制度です。以下のライセンス、活動状況、パッケージの記録を 2026 年 10 月 5 日に改めて確認しました。各ステータスの記述には、根拠となる記録へのリンクがあります。

重要なポイント

• 機能一覧より先に、セッションの要件を確認しましょう。Oculix、OpenRPA、taskt は GUI を中心としたツールで、ローカルのデスクトップ作業にはグラフィカルセッションが必要です。RPA Framework は、ブラウザー、ファイル、データの処理では必要ありません。TagUI と UI.Vision は使用するモードによって異なります。
• RPA Framework は 2026 年の 2 月、3 月、5 月、6 月、8 月、10 月にリリースしており、今回確認した中で最も安定したリリース実績があります。
• TagUI は Apache-2.0 ライセンスで、今も貢献を受け付けていますが、AI Singapore は保守とサポートを終了しました。Python ラッパーは 2023 年 7 月以降リリースされていません。
• Automagica と OpenBots は、現在の候補には入りません。Automagica は 2020 年 10 月に Netcall が会社を買収した際に AGPL3 ではなくなり、OpenBots には保守されている RPA 製品の公開リポジトリがありません。
• 連携するシステムがすでに API や webhook を公開しているなら、必要なのは RPA ではなくワークフロー自動化です。カテゴリもツールも異なり、構築にかかる時間もずっと短くなります。

本記事が扱わないこと

関連する次の三つの問いは、それぞれの理由で対象外とします。

• 無料枠のある商用プラットフォーム。UiPath Community Edition や Power Automate の無料プランは、ここで扱うものとは別の選択です。
• インストールと設定。以下はセットアップガイドではなく、どのツールについてもコマンドラインの手順は示しません。
• AI によるコンピューター操作エージェント。リストの一つにはそのようなエージェントとの連携がありますが、一文で触れるだけで比較は行いません。

現在も保守されているオープンソース RPA ツール

以下の六つのプロジェクトは、この記事の基準を満たしています。実際にオープンソースの RPA ソフトウェアであり、2025 年半ば以降に公開された活動があることです。保守が止まった無料 RPA ツールも無料であることは変わらないため、最も注目すべきなのはライセンスの列ではなく、日付の列です。他の列では各ツールの自動化対象と、その下で動くマシンに求めるものを示しています。

rpaframework はアプリケーションではなく、ライブラリの集合です。Python または Robot Framework でコードを書き、必要な部品をインポートします。マクロを記録するより導入のハードルは高くなりますが、保守はずっと楽になります。リポジトリでは、Robocorp がこのライブラリを中心に構築した商用オーケストレーション製品、Control Room に最適化されていると説明されています。r/rpa のスレッドに参加した Sema4.ai のチームメンバーは、Robocorp が現在 Sema4.ai の一部であると述べ、境界を明確にしています。ライブラリは Apache-2.0 ですが、プラットフォームはそうではありません。所有者は変わっても、その境界は変わっていません。基盤となる Robot Framework も Apache-2.0 であり、別の候補として挙げるものではありません。

UI.Vision のオープンソースの中核はブラウザー拡張機能です。デスクトップ自動化には、別途ダウンロードするローカルアプリ XModulesを使います。画像とテキストの認識機能を拡張機能に与え、ブラウザーの外にあるものをクリックできるようにします。ライセンスはデュアル方式（AGPLv3 または商用契約）です。オープンソースの中核を変更し、AGPLv3 のソース共有条件に従いたくない場合は、商用ライセンスを選べます。

taskt は判断に困る候補です。開発ブランチには 2025 年 7 月にコミットがありましたが、最後のタグ付きリリース v3.5.0.0 が公開されたのは 2020 年 5 月です。コミットとリリースは異なる兆候であり、バージョン付きビルドがこれほど長く出ていないからといって、既存のビルドが動かなくなったわけではありません。

SikuliX には独立した注記が必要です。この名前は実質的に旧系統を指すようになったためです。元の上流リポジトリは 2026 年 3 月にアーカイブされ、oculix-org のミラーは現在のユーザーを Oculix に案内しています。Oculix は MIT ライセンスのもとで活動を続ける後継プロジェクトです。したがって、現在候補に入れるべきなのは Oculix であり、SikuliX1 は保守中の候補ではなく、系譜や互換性の背景として役立ちます。

候補リストに繰り返し登場するものの、含めるべきではないプロジェクトが二つあります。Automagica 自身の README は、2020 年 10 月 13 日に Netcall が会社を買収し、ロボットがAGPL3 では提供されなくなったと告知しています。一方、OpenBots の公開 GitHub 組織にあるのは静的サイトのリポジトリと端末エミュレーションライブラリで、RPA の中核はありません。

GUI 依存かヘッドレスか：サーバー選びを決める分岐点

ワークフローがデスクトップ UI の自動操作に依存する場合、オープンソース RPA ツールにはデスクトップセッションが必要です。API、ファイル、データの自動処理はヘッドレスで実行でき、ブラウザーをヘッドレスモードで動かす場合にはブラウザーの自動操作も可能です。画像認識ツールにはさらに解析対象のピクセルが必要ですが、画像ではなくセレクターでコントロールを識別する場合でも、デスクトップ自動化はグラフィカルセッションに依存し得ます。

デスクトップセッションとは、ユーザーがサインイン後に使うグラフィカル環境です。画面、ウィンドウマネージャー、座標を持つマウスポインターが含まれます。ヘッドレスはその逆で、ディスプレイを接続せずにマシンが動いている状態です。レンタルする Linux サーバーの多くは、標準でヘッドレスです。

この分類は、自動化が何に依存するかによって決まります。Oculix は以前の SikuliX と同様に、保存した画像を現在画面にあるピクセルと照合するコンピュータービジョンでボタンを探すため、解析できるグラフィカルな表示領域が必要です。自動操作 API を通じて制御するブラウザーは、デスクトップ画面なしでヘッドレス実行できます。セレクター方式のデスクトップ自動化はまた別です。ピクセルではなくコントロールを識別しても、グラフィカルなデスクトップ環境に依存する場合があります。サーバー上のオープンソース RPA では、ワークフローにグラフィカルセッションが必要かどうかが実際の判断基準になります。

TagUI と UI.Vision は両方にまたがっており、どちらになるかは使用モードで決まります。TagUI 自身のリファレンスでは、-headless オプションは非表示の Chrome ブラウザーでフローを実行し、視覚的な自動化では機能しないと説明しています。UI.Vision のブラウザー処理は拡張機能内で動き、デスクトップ処理は XModules 経由です。XModules は画面の画像を認識するため、認識対象の画面が必要です。

仮想ディスプレイは、この隔たりを一部埋めます。Xvfb はヘッドレスの Linux マシンにメモリ上のディスプレイを与える標準的な方法です。誰も見ていなくてもグラフィカルプログラムがそこに描画できるため、モニターのないサーバーで画面操作による自動化が可能になります。ただし、Windows 専用ツールを Linux で動かせるようにはならず、午前 3 時にも動き続けなければならない層が一つ増えます。

ライセンスとコミット日からは、来年もツールが存在するかを判断できます。セッションの要件からは、そもそも実行できるかが分かります。

各ツールをどこで動かすか

画面を操作するボットには、制御できるグラフィカルセッションが必要です。実際のデスクトップでも、リモートセッションでも、仮想ディスプレイでも構いません。ヘッドレスのボットには不要です。どちらも当たり前に聞こえますが、キーボードの前に誰もいない午前 3 時にボットを起動しなければならないと、話は変わります。

セルフホスト型 RPA には、どのツールを選んでも残る運用要件があります。スケジュールが発動するとき、マシンが正しい状態でなければなりません。Windows ではその状態が具体的に定められており、Microsoft は自社製品について正確に文書化しています。Power Automate の無人デスクトップフローに関するガイドでは、製品が対象マシンにリモートデスクトップセッションを作成してフローを実行すること、無人実行ではマシンのコンソールセッションへの接続が利用できないこと、そして Windows 10 または Windows 11 のデバイスは、ロックされたものも含めてユーザーセッションが存在すると無人フローを実行できないことが説明されています。Windows Server では、接続と同じユーザーで開いているロック済みセッションがあるとエラーになります。

これは一社の実装であり、Windows 全般の法則ではありません。ただし、画面操作型のボットはすべて同じ問題を解決する必要があるため、障害の起こり方を理解する手掛かりになります。何かが対話型セッションを占有する必要があり、自分がログインしているデスクトップはたいていその妨げになります。Linux では同じ問題は小さくなりますが、なくなるわけではありません。SSH セッションを閉じても実行を続けるジョブに必要なのは、開いたままの端末ではなく、スケジューラーとサービスマネージャーです。

Windows Server のセッション処理はデスクトップ版とは異なります。RD Session Host ロールは、複数セッションを効率よく扱うために一台のマシンでセッションベースのデスクトップを実行するので、ボットのセッションと自分のセッションが共存できます。RD Session Host で複数セッションを運用する場合、接続するユーザーまたはデバイスごとに RDS CAL が必要です。これは後から気付く細部ではなく、早い段階で見積もるべき費用です。

必要なリソースはそれほど大きくありません。フォームをクリックしてファイルを書き出すボットなら、私は 1 vCPU と 2 GB の RAM を超える構成にはしません。フルブラウザーを操作するなら、特に複数タブを使う場合、2 vCPU と 4 GB 以上を割り当てます。その処理でリソースを消費するのは、上で動く自動化ツールより Chrome だからです。

物置にある古いマシンでも、この条件は満たせます。ただし、電源を入れたまま、ログインしたままにする必要があり、夜に閉じるノートパソコンではいけません。レンタルサーバーなら、ノートパソコンとは独立して稼働し続けられ、作業用デスクトップのセッションと競合しないため、この種の問題を解消できます。

自分でマシンを保守するより借りるほうがよいなら、この分類は二つの製品にかなり素直に対応します。Desktop または Server イメージを実行する Windows VPS は、画面操作型ボットに専用の Windows 環境を提供します。Linux VPS はヘッドレス側を担い、どちらもノートパソコンを開いているかどうかに関係なく動作します。

どれを選ぶべきか

作業がブラウザーやファイルの中で完結し、Python を書けるなら、選ぶのは RPA Framework です。この節の残りは例外的な状況について扱います。API のないデスクトップアプリに作業が及んだ瞬間に答えは変わります。グラフィカルなデスクトップと対話できるツールが必要になり、候補は少なく、古くなるためです。

Linux サーバーでブラウザー、ファイル、データを扱うなら、RPA Framework を選びましょう。ヘッドレスで動作し、ディスプレイのないマシンにも追加の仕組みなしで導入でき、2026 年 10 月にも新バージョンがリリースされています。代わりに、マクロを録画するのではなく Python または Robot Framework で書く必要があります。初日は負担になりますが、対象アプリが変更されるたびに、その投資が報われます。

API のない古い Windows アプリで、完全な自動化コードベースを書くより視覚的な自動操作を望むなら、条件付きで UI.Vision を選びましょう。今年もコミットがあり、ここで挙げたデスクトップ対応の候補すべてがそうではありません。一方、デュアルライセンスの AGPLv3 側には、オープンソースソフトウェアを変更して配布する場合にソース共有義務があります。この用途の第二候補は taskt です。開発ブランチは動いていますが、最後のタグ付きリリースは 2020 年 5 月です。コミットを受け付けるプロジェクトと、バージョンを出すプロジェクトの間にある隔たりを評価する必要があります。

画面にあるものをプラットフォームを問わず視覚的に自動操作するなら、SikuliX の活動を継承する Oculix を選びましょう。セレクターより画像を優先する点は変わりませんが、現在は単なる画像照合の基本機能群ではなく、IDE があり、活発にリリースされています。DOM やアクセシビリティツリーではなく、ピクセルが対象の場合に使い、アーカイブされた SikuliX1 リポジトリは保守中の製品ではなく旧系統として扱いましょう。

TagUI が繰り返し勧められるのには理由があります。スクリプト言語は平易な英語に近く、六つの中で学習のハードルが最も低いからです。それと比較すべき事情は、自身の README に書かれています。そこでは、AI Singapore が保守を終了したとし、サポートも終了した一方で、プロジェクトはオープンソースの貢献者とコミュニティによって続いていると説明しています。これは放棄ではありません。貢献者は今もデフォルトブランチに修正を加え、リポジトリもアーカイブされていません。ただし、勢いがあるとも言えず、PyPI の rpa Python ラッパーはコミット履歴から何年も遅れています。TagUI は、更新を止めても差し支えない作業に選ぶべきで、3 年間拡張する予定のプラットフォームには向きません。

OpenRPA は判断が難しい選択です。MPL-2.0 のもとで本格的なオーケストレーション機能がありますが、最後のコードコミットも最新のタグ付きリリースもともに 2025 年 6 月のもので、それ以降のリポジトリの動きは自動生成された依存関係更新用のブランチだけです。何もアーカイブされていないので放棄ではありませんが、新たにリリースされたものもありません。その隔たりと、ボットを動かし続ける期間を比較して判断してください。

専用 RPA ツールが適切な答えではない場合

上記のすべてに対する最も強い反論は、この仕事の実務者から出ています。商用 RPA 契約から抜け出そうとする運用担当者が始めたr/selfhosted のスレッドで、ある返信は代わりに Python と Selenium などの自動化フレームワークを使うことを勧めています。構築には手間がかかっても、できてからの故障が少なく、その投稿者が使った RPA ソフトウェアより継続的な所有コストが低いという意見です。同じスレッドの別の投稿者も、独立して同意しています。

分かれ目は保守です。作業を何年も実行する予定で、処理量が多く、自分かチームの誰かが小さなコードベースを維持できるなら、コードを書きましょう。Selenium と Playwright は初日の負担が大きくても、400 日目の負担は小さくなります。自分で書いたスクリプトなら、壊れ方を読み解けるからです。作業の期間が数か月程度か、チームにコードを書く人がいないなら、動くボットまでの道のりが短い RPA ツールには、その壊れやすさを受け入れる価値があります。

最も古くなりやすいのは、レコーダーが出力する部分です。クリックを観察して生成したスクリプトは、記録時のレイアウトに縛られます。そのため、ページのデザイン変更やボタンの移動で壊れても、エラーメッセージが原因を説明してくれることはめったにありません。このカテゴリへの疑念は、場所によってはさらに深くなります。オープンソースの選択肢を扱う r/rpa のスレッドのある投稿者は、RPA を非技術系の管理職に販売するために包装し直したスクリプトだと呼んでいます。十分に限定された作業なら、不当な表現とは言えません。

早めに見抜くべきカテゴリの取り違えもあります。連携するシステムが API や webhook を公開しているなら、そもそも RPA は不要です。RPA がユーザーインターフェースを操作するのは、他に入口がないからです。ワークフロー自動化はその入口を直接呼び出すので、構築が速く、はるかに壊れにくくなります。これは異なるコスト構造を持つ別のツール群であり、まず確認すべきはn8n のライセンスとセルフホストの費用です。今日から動かしたいなら、当社のマーケットプレイスには n8n、Node-RED、Apache Airflow、Kestra、Dagu のワンクリックアプリがあります。

UI.Vision の現在のサイトは Anthropic Computer Use との連携を紹介しています。このカテゴリはすでに、保存画像との照合ではなく、画面について推論して操作するエージェントを取り込みつつあります。

よくある質問

UiPath はオープンソースですか？

いいえ。UiPath は商用プラットフォームで、Community Edition はソースを公開するのではなく無料の利用権を提供します。UiPath の Community Agreement が条件を定めており、ソフトウェアの逆コンパイルとリバースエンジニアリングの禁止も含まれます。オープンソースの UiPath 代替製品は、Apache-2.0、MIT、MPL-2.0、AGPLv3 でコードを公開するプロジェクトです。

TagUI は今も保守されていますか？

元の保守担当者による保守は終了しています。TagUI の README は、AI Singapore が保守とサポートを終了し、プロジェクトはオープンソースの貢献者とコミュニティによって続くと説明しています。リポジトリはアーカイブされておらず、今もコミットがあり、デフォルトブランチの最新コミットは 2026 年 9 月 20 日です。ただし、2025 年 3 月からその修正まで、ブランチは変更されていませんでした。PyPI の rpa Python ラッパーは今もバージョン 1.50.0 で、リリース日は 2023 年 7 月 7 日です。

デスクトップのない Linux サーバーで RPA ボットを動かせますか？

はい。API、ファイル、データの自動処理と、ヘッドレス実行に設定されたブラウザーの自動操作なら可能です。デスクトップ UI の自動操作には通常、グラフィカルセッションが必要です。Linux では Xvfb などの仮想ディスプレイを用意すれば、それ以外はヘッドレスのサーバーでも、画像によるワークフローを実行できる場合があります。

Robocorp の買収後も RPA Framework はオープンソースですか？

ライセンスとリリース記録を見る限り、はい。rpaframework は自身のリポジトリで Apache-2.0 を採用しており、Robocorp が Sema4.ai の一部になってからかなり後の 2026 年 10 月 4 日に、バージョン 33.0.2 を PyPI に公開しています。ライブラリを中心に構築されたオーケストレーション製品 Control Room は、会社の所有者が変わる前から商用側に属しており、今も変わりません。

Windows 専用ではなく、macOS や Linux で動くオープンソース RPA ツールはどれですか？

taskt と OpenRPA を除くすべてです。この二つが Windows 専用なのは、パッケージングの選択ではなく構造上の理由です。taskt のリポジトリではC# で .NET Framework 上に構築されていると説明され、OpenRPA は Windows デスクトップアプリを自動操作するため、どちらも Linux や macOS 向けのビルドを提供していません。他の四つはクロスプラットフォームです。UI.Vision は三つのプラットフォームすべて向けに XModules を提供し、Oculix は Windows、macOS、Linux で動作し、RPA Framework は Python が動く環境ならどこでも実行できます。TagUI の README もWindows、macOS、Linux で動作すると記しています。