AstronRPA を採用する前に確認すべき構成と制約

誰のための RPA なのか、想定読者を先に決める

AstronRPA が解こうとしているのは、業務担当者が GUI しか持たない業務システムを跨いで手作業を繰り返している状態だ。README は「enterprise-grade Robotic Process Automation (RPA) desktop application」と位置づけ、視覚的なデザイナで low-code/no-code のワークフローを組めると説明している。つまり主対象は、Python や Java を書ける開発者ではなく、業務フローを理解しているがコードは書かない運用担当者である。

ただし、これは純粋なノーコードツールではない。ビルドには Node.js 22 以上、Python 3.13.x、JDK 8 以上、pnpm 9 以上、UV 0.8 以上、7-Zip、SWIG が必要だと BUILD_GUIDE に記載されている。ワークフローを組む人はコードを書かなくてよいが、環境を立ち上げる人は相当なツールチェーンを扱える必要がある。この非対称性は導入時に必ず効いてくる。評価するなら、まず誰がサーバーを立て、誰が業務フローを組むのかを分けて考えたほうがよい。

サーバーとクライアントに分かれる二層構成

構成は素直に二層である。サーバー側は Docker Compose で一式を立ち上げ、クライアント側は Windows 10/11 のデスクトップアプリとして動く。README のシステム要件はクライアント OS を Windows 10/11 (primary support)、RAM を 8 GiB 以上としている。ここで primary support と書かれている点は読み飛ばせない。Windows 以外が動かないとまでは書かれていないが、主要サポート対象は Windows だと明言している。

サーバー側では認証を Casdoor が担当する。docker compose up -d の後、ブラウザで http://{YOUR_SERVER_IP}:32742/api/rpa-auth/user/login-check を開き、{"code":"900001","data":null,"message":"unauthorized"} が返ればデプロイは正しいと README は説明している。認証エラーが正常応答の確認に使われているのは少し独特だが、API が生きていることの確認としては筋が通っている。別途 http://{YOUR_SERVER_IP}:8000 で Casdoor のログイン画面が出れば認証基盤も正常という切り分けになる。

RPA エンジンの実体は Python 3.13 で、クライアントに同梱される。ビルドスクリプトは Python 環境を build/python_core にコピーし、resources/python_core.7z として圧縮する。つまりエンジンはサーバーではなく各端末で動く。この設計は、端末上のデスクトップアプリを操作するという RPA の性質上避けられない。その代わり、端末ごとに Python 環境のサイズと依存関係を配布しなければならないという運用負荷を引き受けることになる。

導入手順のうち、実際に詰まる三か所

サーバーは README の手順どおりで進む。git clone の後、cd docker、cp .env.example .env、そして .env 内の CASDOOR_EXTERNAL_ENDPOINT="http://{YOUR_SERVER_IP}:8000" を書き換えて docker compose up -d を実行する。docker compose ps で状態を確認する流れだ。ここで IP を書き換え忘れると、コンテナは起動しても認証が通らない。最初のつまずきはほぼここである。

クライアントはリリースパッケージをダウンロードする方法と、自前でビルドする方法がある。ビルドする場合は ./build.bat --python-exe "C:\Program Files\Python313\python.exe" のように Python の実行ファイルを明示する。引数を省略した ./build.bat も可能だが、その場合は Python が既定のパスにあることが前提になる。コンソールに Full Build Complete! と出れば成功という判定方法が README に示されている。

インストール後にもう一段設定が要る。インストールディレクトリの resources/conf.yaml を開き、remote_addr を自分のサーバーに向ける。既定は remote_addr: http://YOUR_SERVER_ADDRESS:32742/ で、skip_engine_start: false というキーも同じファイルにある。このファイルを直さないまま起動すると、クライアントはどこにも繋がらない。サーバー側の .env とクライアント側の conf.yaml、この二つのアドレス設定が揃って初めて動作する。

エージェント連携と MCP が意味するもの

このプロジェクトの差別化点は、RPA を単体の自動化ツールとしてではなく、エージェントから呼べる部品として扱う方向にある。README は Astron Agent を「native Agent platform supported by this project」と説明し、Astron Agent 側から RPA のワークフローノードを直接呼べること、逆に AstronRPA 側で Agent のワークフローを使えることを挙げている。双方向だという点が重要で、片方向の連携ではない。

トリガーの種類も README に列挙がある。直接実行、スケジュールタスク、スケジューリングモード、API 呼び出し、そして MCP サービスである。トピックにも mcp と llm が入っており、外部システムに埋め込む経路が複数用意されていることになる。

ただし、ここは文書が薄い。Agent 連携が具体的にどのプロトコルで、どの認証を通り、どの粒度でノードを公開するのかは README からは読み取れない。双方向呼び出しという表現だけでは、疎結合なのか密結合なのかが判断できない。エージェント連携を主目的に評価するなら、この部分は実際に動かして確かめる以外にない。README の記述量から期待値を上げすぎないほうがよい。

300 以上のコンポーネントという数字の読み方

README は「300+ pre-built atomic capabilities」として UI 操作、データ処理、システム連携をカバーすると述べ、対応先として WPS や Office、Kingdee や YonYou といった業務ソフト、IE、Edge、Chrome といったブラウザを挙げている。IE が今も列挙されているのは、国内の業務システムに未だ IE 前提のものが残っている事情を反映しているのだろう。古い対象を切らずに残す判断は、エンタープライズ向けとしては現実的である。

一方で、コンポーネント数は成熟度の指標にはならない。300 という数が何を一単位としているのかは README からは分からない。UI 操作の一アクションなのか、複数ステップのまとまりなのかで意味が変わる。カスタムコンポーネント拡張が可能と書かれているので、足りない部分は自分で足す前提だと考えたほうがよい。

対象ソフトの列挙についても、対応の深さは書かれていない。Kingdee や YonYou と一口に言っても製品は複数あり、バージョンによって UI は変わる。導入検討では、自分の環境のそのバージョンで動くかを個別に確認する作業が発生する。この確認を省いて全体導入に進むと、後工程で詰まる。

Windows 前提という制約と、向かないケース

最も明確な制約はクライアントが Windows 10/11 前提であることだ。README は RAM 8 GiB 以上も要件に挙げている。RPA エンジンが端末側で動き、その端末のデスクトップアプリを操作するのだから、これは設計上の必然であって実装の手抜きではない。だが結果として、Linux のサーバーだけで完結する自動化や、macOS 中心の開発組織にはそのままでは合わない。

もう一つの制約はビルドの重さである。Node.js、Python 3.13.x、JDK 8+、pnpm、UV、7-Zip、SWIG を揃えたうえで、Python 環境をコピーして 7z に圧縮する。README はこのとき「clean installation without additional third-party packages」の Python を使うよう注意している。追加パッケージが入った Python を使うと、その分が python_core.7z に乗って配布物が膨らむ。開発機で何となく使っている Python をそのまま指定すると、この注意を踏み抜く。

自前ビルドを避けたい場合、リリースパッケージのダウンロードが推奨として示されている。ビルドツールチェーンを維持するコストを見積もったうえで、どちらを選ぶかを決めることになる。ビルドを選ぶなら、CI にこれだけのツールを揃える前提で考えておく必要がある。

代替としての UiPath と、設計思想の違い

商用の代表格である UiPath と比べると、違いは導入の形にはっきり出る。UiPath は Orchestrator を中心としたマネージドな管理基盤と、クラウドまたは自社サーバーでの運用を組み合わせ、エージェントやロボットの管理を製品側が担う。AstronRPA はサーバー一式を docker compose up -d で自分のホストに立て、認証も Casdoor を自分で設定する。管理の責任範囲が利用者側に寄っている。

この違いは、データの扱いを自分で握りたい場合に効く。トピックに on-premise、self-hosted、data-privacy、security-compliance が並んでいるのは、閉域で完結させたい需要を意識している表れだろう。逆に、管理基盤の運用を製品に任せたい、サポート契約が欲しいという組織には、自前で Docker と Casdoor を面倒みる構成は負担になる。

もう一つの違いはエージェント連携の位置づけだ。AstronRPA は Astron Agent との双方向呼び出しを前面に出す。RPA を既存のエージェント基盤に組み込む前提で設計されている。UiPath 側もエージェント機能を広げているが、AstronRPA の場合は連携先が iflytek の Astron Agent に事実上寄る。既に Astron Agent を使っているなら噛み合うが、別のエージェント基盤を採用している組織にとっては、この連携は魅力にならない。MCP 経由で繋ぐことはできるが、README からはその詳細が読み取れない。

Apache-2.0 と、運用コストの見積もり

ライセンスは Apache-2.0 である。特許の明示的な許諾を含み、改変物の配布時に変更点を示すなどの条件が課される。商用利用を禁じる条項は含まれていない。ただし、これは法的助言ではない。自組織の配布形態が条件に当たるかどうかは、必要なら専門家に確認する話である。

維持コストとして現実的に効くのは、コンテナ群の更新である。リリースは v1.1.6 が 2026-02-25、v1.1.5 が 2026-01-29 と、約一か月間隔で版が上がっている。nightly のプレリリースも別途出ている。このペースだと、追従するか、特定版で止めて四半期ごとにまとめて上げるかを最初に決めておかないと、更新が滞留する。

クライアント側の更新も忘れてはならない。エンジンは端末に同梱されるので、サーバーだけ上げるとクライアントとのバージョン差が生じる。台数分の配布経路を用意する必要がある。ビルドを自前で回す場合、Python 3.13 のクリーン環境を都度用意する手間も毎回発生する。サーバーとクライアントの両方に更新経路を持つ前提で、運用体制を先に設計しておくべきだ。

編集部の結論

採用を検討すべきなのは、Windows デスクトップと業務システムの操作を自社サーバー内で完結させたい組織、特に WPS や Office、Kingdee や YonYou のような国内業務ソフトの自動化が要件にある場合だ。逆に Linux や macOS しかない環境、あるいはクラウドのマネージド RPA で十分なチームには向かない。導入前に確認すべきは三点。第一に docker/.env の CASDOOR_EXTERNAL_ENDPOINT を自サーバーの IP に書き換えないとログインが通らないこと。第二にクライアント側の resources/conf.yaml の remote_addr がサーバーを指していないと起動後すぐ接続に失敗すること。第三にビルドに使う Python 3.13 が追加パッケージの入っていないクリーンな環境でなければ python_core.7z が肥大化すること。この三点を潰せないなら、評価の段階で止めておくのが妥当だ。

公式情報源

1. iflytek/astron-rpa on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases