microsoft/UFO とは何ですか？

Windows の GUI 操作を LLM で自動化する UFO² と、複数端末を DAG で束ねる UFO³ Galaxy の二層構成を、README とリポジトリ構成から読み解く。単一端末なら UFO²、異種端末の協調が要るなら Galaxy という判断軸がどこまで資料で裏づけられるかを確認する。

microsoft/UFO は商用利用できますか？

できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

microsoft/UFO は今もメンテナンスされていますか？

されています。最後のコミットは 1 日前です。

microsoft/UFO はどのプログラミング言語で書かれていますか？

主に Python です（GitHub の言語統計による）。

microsoft/UFO 採用判断: UFO² と UFO³ Galaxy の違いと導入手順

ひと目でわかる

これは何？: Windows の GUI 操作を LLM で自動化する UFO² と、複数端末を DAG で束ねる UFO³ Galaxy の二層構成を、README とリポジトリ構成から読み解く。単一端末なら UFO²、異種端末の協調が要るなら Galaxy という判断軸がどこまで資料で裏づけられるかを確認する。
誰に向いている？: 単一の Windows 端末でアプリ横断の操作を自動化したいなら UFO² を選ぶ。README は UFO² を LTS（長期サポート）と位置づけ、Galaxy を active development と明記しているので、安定運用を優先する現場は UFO² 側に留まるのが素直な判断になる。
商用利用できる？: できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。最後のコミットは 1 日前です。
何の言語で書かれている？: 主に Python です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月16日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · microsoft/UFO

UFO が解こうとしている問題は「GUI しか持たない操作」の自動化である

Windows 上の業務の多くは、API が公開されていないデスクトップアプリの操作として存在する。README は UFO² を「Deep Windows OS integration」と「Hybrid GUI + API actions」という特徴で説明しており、GUI 操作と API 呼び出しを混ぜて一つのタスクを遂行する設計だと読み取れる。対象読者は、RPA のように座標やウィンドウハンドルを固定するのではなく、画面の状態に応じて次の操作を選ばせたい開発者だ。UFO² のタスクモデルは README の比較表で「Sequential ReAct Loop」とされており、推論と行動を交互に回す逐次ループである。つまり、一つのアプリの中で手順が連続する処理に向く。逆に、複数の端末にまたがる処理や、依存関係のある複数タスクを並行で走らせる処理は UFO² の守備範囲外で、README の比較表でも Cross-Device Collaboration は UFO² について「Not Supported」と明記されている。ここが UFO³ で Galaxy が追加された理由である。

Galaxy の中心にある Constellation と DAG 書き換え

UFO³ の設計は README では五つの原則として並んでいる。一つ目が「Declarative Decomposition into Dynamic DAG」で、要求を TaskStars と依存関係からなる構造化 DAG に分解し、スケジューリングと実行時の書き換えを行うと説明される。二つ目が「Continuous Result-Driven Graph Evolution」で、実行フィードバックに応じてグラフを制御的に書き換える「living constellation」という表現が使われている。ここは他の GUI エージェントとの差がはっきり出る部分だ。多くのエージェントは計画を一度立ててから逐次実行するが、Galaxy は実行結果を計画そのものに反映させる前提で設計されている。三つ目は「Heterogeneous, Asynchronous & Safe Orchestration」で、capability ベースの端末マッチング、非同期実行、安全ロック、形式的検証による正しさが挙げられている。四つ目が「Unified Agent Interaction Protocol (AIP)」で、WebSocket ベースの調整層、障害耐性、自動再接続が特徴とされる。五つ目が「Template-Driven MCP-Empowered Device Agents」で、MCP 統合によってツールを拡張する軽量なエージェント開発キットだと説明されている。役割分担は比較表で ConstellationAgent と TaskOrchestrator という名前が示され、UFO² の HostAgent と AppAgents とは別物として整理されている。

導入は UFO² と Galaxy で入口が分かれる

README の Quick Links は三つの文書を指している。galaxy/README.md、ufo/README.md、そしてオンラインドキュメントの https://microsoft.github.io/UFO/ だ。Galaxy のクイックスタートは getting_started/quick_start_galaxy/ に置かれていると README に記載があるので、Galaxy を試す場合はそちらを読む順序になる。Python の対応バージョンはバッジで 3.10 と 3.11 が示されており、それ以外のバージョンでの動作は資料からは確認できない。ライセンスは MIT で、リポジトリの LICENSE バッジも MIT を示している。UFO² から Galaxy への移行については README に Migration Path の節があり、UFO² をそのまま使い続ける選択、Galaxy の Windows device agent として UFO² を使う段階的採用、そして規模を広げる段階の三つが示されている。つまり Galaxy は UFO² を置き換えるのではなく、UFO² を端末側のエージェントとして組み込める関係にある。この点は導入計画に効く。既に UFO² で動いている資産があるなら、Galaxy 側のオーケストレーションだけを新規に立てる進め方が README の記述と整合する。

対応端末の広さと、その広さが持ち込む制約

比較表では Device Support が UFO² で Windows Desktop、UFO³ Galaxy で Windows、Linux、Android（more coming）と書かれている。異種プラットフォーム統合が Galaxy の売りである一方、この広さは調整コストに直結する。AIP が WebSocket ベースだと明記されている以上、端末間でその接続が通る必要があり、閉域網や端末ごとに異なるプロキシ設定がある環境では、この層が最初の詰まりどころになる。README は AIP に自動再接続と障害耐性があるとしているが、切断そのものを防ぐ仕組みについては記述がない。もう一点、比較表は Galaxy の Status を「Active Development」とし、UFO² を「LTS (Long-Term Support)」としている。同じリポジトリの中に成熟度の異なる二つの層が同居しているわけで、Galaxy の API や設定キーがリリースごとに動く可能性を前提に置くべきだ。実際、直近のリリースは v3.0.8（2026-08-10）、3.0.7（2026-06-12）、3.0.6（2026-06-06）と、2か月から3か月の間隔で並んでいる。パッチ番号の刻み方からは破壊的変更の有無までは読み取れないので、採用時はリリースノートを追う必要がある。

Galaxy が過剰になる場面

一つの Windows アプリで完結する定型処理に Galaxy を持ち込むのは、構成要素を増やすだけで見合わない。README の比較表でも Complexity は UFO² が「Simple to Moderate」、Galaxy が「Simple to Very Complex」とされ、Setup Difficulty は UFO² が Easy、Galaxy が Moderate と明示されている。単一端末の逐次タスクなら、UFO² の HostAgent と AppAgents の関係を理解するほうが学習量は小さい。また、GUI 操作そのものが不要な処理、たとえば公開 API だけで完結するバッチには、そもそもこの種のエージェントは要らない。README が想定しているのはあくまで GUI と API の混在したデスクトップ操作であり、ヘッドレスなサーバ処理は射程に入っていない。もう一つ、README は Galaxy の原則の一つに「Safe Orchestration」と「formally verified correctness」を挙げているが、この形式的検証が何を対象に、どの範囲で成立するのかは README の記述からは分からない。安全性の主張を根拠に重要業務へ投入するなら、その検証範囲を論文側（arXiv:2511.11332）で確認する必要がある。README だけでは、この主張を採用判断の決め手にはできない。

比較対象としての Windows ネイティブ自動化

同じ Windows 自動化の領域には、PowerShell と UI Automation、あるいは WinAppDriver のような仕組みがある。これらは画面要素をセレクタで指定し、手順をコードとして固定する。決定的な違いは、次の操作を誰が決めるかだ。UFO² は README の比較表にあるとおり Sequential ReAct Loop を採り、画面の状態を読みながら LLM が次の行動を選ぶ。セレクタが変わっても LLM 側が別経路を選べる余地がある反面、同じ入力でも経路が毎回同じになる保証はない。UI Automation 系は再現性と決定性が高いが、アプリの更新でセレクタが変われば手順そのものが壊れる。したがって、監査可能な手順の再現性が要件なら UI Automation 系、画面の揺れに追随させたいなら UFO² という切り分けになる。Galaxy はさらに一段上で、複数端末へのタスク配分を DAG として扱う。単一端末の自動化ツールと Galaxy を比べても軸が違う。Galaxy の比較対象は、複数ホストに処理を配るジョブスケジューラやオーケストレータであり、違いは各ノードが GUI エージェントである点にある。

MIT ライセンスと保守コストの見積もり

ライセンスは MIT で、リポジトリのバッジも MIT を示している。MIT は商用利用や改変、再配布を許容する寛容なライセンスだが、無保証である点は変わらない。ここから先は法的助言ではないが、社内のライセンス確認プロセスに通す際は、同梱される依存パッケージのライセンスを別途確認する必要がある。UFO 本体が MIT だからといって、依存関係全体が MIT であるとは限らない。保守の観点では、リポジトリは archived ではなく、最終 push は 2026-09-09、直近リリースは v3.0.8（2026-08-10）となっており、資料の範囲では継続的に更新されている。ただし Galaxy は Active Development と自己申告されているため、UFO² を LTS として据え、Galaxy 側の更新には追随コストを見込む二本立ての見積もりが現実的だ。Python 3.10 と 3.11 という対応バージョンの幅も、社内の標準ランタイムが 3.12 以降であれば別途検証が要る。README にはそれ以外のバージョンでの動作可否は書かれていない。

編集部の結論

単一の Windows 端末でアプリ横断の操作を自動化したいなら UFO² を選ぶ。README は UFO² を LTS（長期サポート）と位置づけ、Galaxy を active development と明記しているので、安定運用を優先する現場は UFO² 側に留まるのが素直な判断になる。逆に、複数端末にまたがるワークフローを DAG で組み、実行中のグラフ書き換えまで求めるなら Galaxy が候補になるが、README 自身がセットアップ難度を Moderate と書いており、学習曲線も Moderate とされる。採用前に確認すべきは三点。第一に galaxy/README.md と online docs の quick_start_galaxy で、対応端末として挙がっている Windows、Linux、Android のうち自分の環境が実際に列挙されているか。第二に AIP が WebSocket ベースだと書かれている以上、端末間の通信経路とポートを自組織のネットワークで通せるか。第三に、UFO² を Galaxy の device agent として流用する構成を取る場合、ufo/README.md 側の前提条件が Galaxy 側の要件と衝突しないか。この三点が資料上で確認できないなら、まず UFO² 単体で導入し、Galaxy は別環境で検証する。

公式情報源

コミュニティノート