UnicomAI/wanwu を採用する前に読む: FDE 向けエージェント基盤の実像

README が想定する読者は『FDE』という職種である

このプロジェクトの説明で最初に目に入るのは、機能一覧ではなく Forward Deployed Engineer（FDE）という職種名だ。README は Wanwu を「all-in-one, commercial-friendly licensed agent development platform」と位置づけ、FDE に必要なツール群を一通り揃えることを狙うと書いている。つまり対象は、顧客企業のシステムの中に入り込み、AI の PoC を本番運用まで持っていく立場のエンジニアである。

この前提は設計判断に表れている。RAG、構造化データの推論、業務フローの自動化、GUI 操作、汎用エージェントという 5 つの能力が、それぞれ独立した製品ではなく 1 つのプラットフォームのモジュールとして並ぶ。現場で「文書検索だけでは足りない」「承認フローに組み込みたい」といった要求が出るたびに別製品を継ぎ足すのではなく、同じ管理画面と権限モデルの上で扱えるようにする、という発想だ。

反面、この職種向けの作りは、社内の情シスが自社利用のために導入するケースとは噛み合わない部分がある。マルチテナントを前提とした権限設計や、顧客先へ持ち込むための配備経路が前面に出ており、単一組織の内製ツールとして使うには設定項目が過剰になりやすい。

5 つのエージェント種別と、それぞれが引き受ける現実の作業

README はコア機能を 5 つに分けている。中身を追うと、それぞれが別の「現場の詰まり」に対応していることがわかる。

RAG/Knowledge Base Agent は、散在する社内文書を扱うための層だ。README によれば 12 種類のファイル形式と URL クロールに対応し、OCR と MinerU モデルのプライベート配備、マルチモーダル検索、カスケード型と適応型のチャンキング、インテリジェントランキング、出典引用を備える。GraphRAG については UniAI-GraphRAG を内蔵し、ドメインオントロジーのモデリングによって文書横断の要約とマルチホップ推論の完全性を高めると説明されている。F1 スコアが「業界最先端」と主張されているが、これは README の自己申告であり、評価データセットや比較条件は示されていない。この点は検証のしようがない。

Ontology Agent は、LLM がテキストしか扱えないという制約を埋める役割を担う。企業データと文書から業務知識ネットワークを自動構築し、知識 Q&A から業務分析へ引き上げるとされる。

Workflow Agent は契約審査や経費承認のような定型業務が対象で、ローコードのドラッグ&ドロップ画面に条件分岐、API、LLM、ナレッジベース、コード、MCP を並べて実行経路を固定する。ここは README の表現を借りれば「zero-code Skill invocation」による閉ループを狙っており、意図認識からスキル実行までを 1 つの作業領域で完結させる。

GUI Agent は API を持たない既存システム向けで、AI が画面を直接見て操作する。各ボットは隔離された Docker コンテナで動くと記述されている。

General Agent と Skill 開発は、これらを自然言語で統合する層だ。1 文からスキルを作成し、プラットフォーム上のアプリをワンクリックでスキルへ変換できるとされる。

配備は 3 経路、ただし GUI Agent だけは別配布である

README が示す配備方法は 3 つ。1 つ目は視覚的な画面からそのまま使う方法で、エージェントやワークフローの作成にコーディングを要さない。2 つ目は RESTful API（BaaS）経由で OA、CRM、ERP に埋め込む方法で、きめ細かい権限制御を備えると説明されている。3 つ目が Skill と UniClaw 専用クライアントの組み合わせで、ローカル PC の操作や DingTalk のメッセージ送信といった高権限の操作を FDE が実行する想定だ。

ここで注意したいのは、GUI Agent だけはプラットフォームに同梱されず、Baidu の pan.baidu.com からクライアントをダウンロードする形になっている点だ。エンタープライズ向けを掲げるプロジェクトで、主要コンポーネントの配布がファイル共有サービス経由というのは、調達やセキュリティ審査の観点で引っかかりやすい。ミラーや checksum の記載は README には見当たらない。この構成を採用できるかどうかは、組織のポリシー次第であり、技術的な優劣とは別の判断になる。

UniClaw のダウンロード先として README に記載されている URL は「https://maas.ai-yuanjing.」で、ドメインが途中で切れている。README が切り詰められた状態で提供されているため、正確な URL は原文を確認する必要がある。

起動までの手順と、そこで見えてくる依存の重さ

README の Quick Start は Docker Compose による起動を案内している。リポジトリを取得し、docker ディレクトリへ移動して compose ファイルを指定して起動する流れだ。

git clone https://github.com/UnicomAI/wanwu.git cd wanwu/docker docker compose -f docker-compose.yaml up -d

README にはこのほか、マイクロサービスを個別に起動するための Makefile と、Docker イメージを自前でビルドするための Dockerfile が用意されていると書かれている。開発時は個別起動、配備時は Compose という使い分けが想定されている。

Go のバージョンは 1.24.0 以上が要求される。README のバッジに明記されており、社内のビルド環境が古い場合はここで止まる。

Compose 一発で立ち上がるとはいえ、RAG の解析、OCR、GraphRAG、ワークフロー実行、GUI 操作のサンドボックスが同じスタックに載る。README は各コンポーネントの最小要件（CPU、メモリ、GPU の有無）を数値で示していないため、どの程度のホストが必要かは起動してみるまで読者にはわからない。PoC を小さく始めたいチームにとって、この情報の欠落は導入判断を遅らせる要因になる。

Dify との違いは『取り込み口』と『構造化データ』にある

比較対象として README 自身が名前を挙げているのは Dify だ。Wanwu は Dify で作成したナレッジベースを API 経由で取り込み、エージェント、チャット、ワークフローから検索に使えると説明している。つまり競合というより、既存の Dify 資産を活かす側に立つ。

両者の違いで実務上大きいのは 2 点ある。1 つは構造化データの扱いだ。Dify はどちらかと言えば文書検索とワークフローが中心で、業務データの推論を前面に出す作りではない。Wanwu は Ontology Agent という独立した層を置き、企業データから業務知識ネットワークを組むとしている。もう 1 つは GUI 操作で、API のないシステムを画面レベルで操作する能力は Dify 側には見当たらない。

ただし Dify の側に利がある点も明確だ。Dify はクラウド版を含む複数の利用形態があり、小規模なチームが最短で動かすまでの距離は短い。Wanwu は Docker Compose で一式を自前運用する前提が濃く、同じ「動くものを見せる」まででも準備の量が違う。既に Dify で動いている資産があるなら、Wanwu を選ぶ理由は構造化データの推論か GUI 操作のどちらかが必要になったときに限られる。

ライセンスは Apache-2.0、ただし『commercial-friendly』の意味を確かめる

ライセンスは Apache-2.0 で、リポジトリのバッジにもそのように表示されている。Apache-2.0 は商用利用、改変、再配布を許容し、特許条項と変更表示の義務を伴う。派生物の扱いについて追加の制限を課す条項は、少なくとも README からは読み取れない。

README は自らを「commercial-friendly licensed」と表現しているが、これは Apache-2.0 という事実の言い換えであって、追加の許諾ではない。中国聯通という企業が公開している点を考えると、ブランドやロゴの利用については別途の条件があり得る。ソースコードのライセンスと商標の扱いは別物なので、製品に組み込む際はロゴや名称の扱いを別途確認したほうがよい。ここは法的助言ではないので、最終判断は自組織の法務に相談してほしい。

もう 1 つ実務的な論点として、Dify のナレッジベースを API で取り込む構成を採る場合、Dify 側のライセンスと API 利用条件が別途効いてくる。Wanwu が Apache-2.0 だからといって、接続先の条件まで緩くなるわけではない。

更新頻度から見るメンテナンスコストの見積もり方

リリースは v0.6.1（2026-07-17）、v0.6.2（2026-07-24）、v0.6.4（2026-09-04）と、おおよそ 1 か月から 1 か月半の間隔で続いている。0.x 系であり、破壊的変更が入る余地は残っていると考えるのが妥当だ。

追従コストを見積もる際に効くのは、どこを自分で触るかである。README の構成に従えば、フロントエンドから Go のマイクロサービス群、RAG の解析パイプライン、ワークフロー実行、GUI 操作のサンドボックスまでが 1 つのリポジトリに入る。ナレッジベースの取り込みロジックやプロンプトをカスタマイズした場合、その差分はリリースごとに手当てが要る。

Compose で一式を動かす場合、アップグレードはイメージの更新とデータ移行の 2 段階になる。README にはデータベースのマイグレーション手順やバージョン間の互換性についての記載が見当たらないため、0.x の間はステージング環境で先に上げて確認する前提で運用計画を立てたほうがよい。

もう 1 点、README に Homepage が設定されていない。ドキュメントの入口がリポジトリ内の README に限られる可能性があり、困ったときに参照できる外部資料の量は未知数だ。導入前に、README 以外にどのようなドキュメントが存在するかを確認しておきたい。

編集部の結論

採用を検討すべきなのは、社内文書の RAG と業務ワークフローを 1 つの管理画面にまとめ、API 経由で OA や CRM に埋め込みたい企業の FDE だ。逆に、単一の軽量なチャットボットを数日で出したい個人開発者や、API を持たないレガシー画面を自動操作したいだけのチームには、Docker Compose の一式を運用する負担のほうが大きい。最初に確認すべきは README の Quick Start にある docker compose の起動が社内のネットワーク制限下で通るか、そして GUI Agent のクライアント配布が Baidu の pan.baidu.com 経由になっている点を自組織のポリシーが許容するかである。

公式情報源

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. UnicomAI/wanwu on GitHub