Sage を採用する前に確認したい5つの論点

Sage が埋めようとしているのは「複雑な作業の途中経過が見えない」という穴である

LLM に長い作業を任せると、途中で何を判断し、どのツールを呼び、どこで失敗したのかが追いにくい。Sage の README は、計画・実行・自己検査・記憶想起・ツール提案という役割の異なるエージェントを組み合わせることで、この可視性の欠落に対処しようとしている。対象読者は、単発のチャット応答ではなく、調査、収集、レポート作成といった複数手順の作業を自動化したい開発者や運用担当者である。README はこれを「A production-ready agent platform」と表現しているが、その主張の裏付けは後述する導入経路と構成要素に依存する。

利用面は一つの入口に閉じていない。デスクトップアプリ、Web、CLI、Chrome 拡張、そして WeChat Personal (iLink)、WeCom、Feishu、DingTalk といった IM チャネルが同じアプリケーションサービス層に接続される。作業を始める場所と結果を受け取る場所を分けられる設計であり、たとえば CLI で流した処理の経過をデスクトップのワークベンチで確認する、という使い方が想定されている。

AgentFlow とサンドボックス: 中核の処理経路

README に掲載された構成図によれば、各入口からのリクエストはまず App Service Layer に集まり、Chat & Sessions、Agent Management、Tasks & Automations、Browser Bridge、Visual Workbench の5つの機能領域に振り分けられる。その下に SAgents Core があり、Session Runtime が AgentFlow を起動し、AgentFlow が Plan、Simple、Fibre、Self-Check といったエージェントを束ねる。計画を立てるエージェントと実行するエージェントを別プロセスではなく同じランタイム上のノードとして扱う点が、この構成の要である。

実行の隔離については、local、passthrough、remote という3種類のサンドボックスが README の機能一覧に挙がっている。local は同一マシン上での分離、remote は外部環境への委譲と読めるが、README 以上の具体的な挙動、たとえばファイルシステムのマウント範囲やネットワーク制限の有無は記載されていない。ここは導入前に必ずソースか wiki.sage.zavixai.com 側のドキュメントで確認したい部分である。ツール側は組み込みツール、Skills、MCP サーバー、ブラウザ自動化、検索、画像生成を一つの実行スタックにまとめるとしており、MCP を採用している点は既存のツール資産を流用しやすい方向の判断だと言える。

動かすまでの手順: dev-up.sh と SAGE_DEFAULT_* 環境変数

Web をソースから起動する場合、前提は Python 3.10+ と Node.js 18+ である。リポジトリを clone したあと ./scripts/dev-up.sh を実行し、http://localhost:5173 を開く。初回は Minimal (SQLite) と Full のどちらのスタックを使うかを尋ねられ、README は Minimal を最短経路として挙げている。独自の Python を使う場合は PYTHON_BIN=... を、uv を使う場合は USE_UV=1 ./scripts/dev-up.sh を指定する。サインイン後、Model Source Management でモデルプロバイダを追加し、エージェントを作成または設定する、という順序になっている。

CLI の場合は pip install -e . のあとに環境変数を設定する。SAGE_DEFAULT_LLM_API_KEY、SAGE_DEFAULT_LLM_API_BASE_URL、SAGE_DEFAULT_LLM_MODEL_NAME、SAGE_DB_TYPE の4つで、README の例では接続先を https://api.deepseek.com/v1、モデルを deepseek-chat、DB を file にしている。設定後は sage doctor で状態を確認し、sage run "Say hello briefly." または sage chat で実行する。TUI は同じ環境変数を設定したうえで sage-terminal を使う。デスクトップ版は Releases から .dmg、.exe、.deb を取得する配布形態で、ソースからのビルドとは経路が分かれている。ここで注意したいのは、SAgents v2 と Desktop v2 が Python 3.12+ を要求するという記述である。バージョン表記が README 内で 1.1.0 と desktop-v1.1.8 に分かれており、どの版がどの Python を要求するのかは導入前に突き合わせる必要がある。

macOS 配布の現実: 公証なしという制約

デスクトップ版の macOS ビルドは Apple の公証を受けていないと README が明記している。そのため初回起動時に Gatekeeper が開発元を確認できない旨の警告を出し、Finder の Applications で Sage.app を右クリックして Open を選び、ダイアログで再度 Open を押すという手順が必要になる。それでもブロックされる場合は System Settings の Privacy & Security から Open Anyway を選ぶ。壊れている旨のメッセージが出る場合は xattr -dr com.apple.quarantine /Applications/Sage.app で隔離属性を外す。

Windows も同様に SmartScreen が未知の発行元として警告し、More info から Run anyway を選ぶ手順が案内されている。これは欠陥ではなく配布ポリシーの選択であり、署名と公証のコストを避ける代わりに、各利用者が初回に例外操作を行う設計だと言える。組織で多数の端末に配る場合、この一手間を MDM 側で吸収できるかどうかが導入コストに直結する。README には MDM 向けの記述はない。

向かないケース: 単発処理とバージョン制約

Sage の構成は、複数手順の作業を分割して実行し、その経過を追うことに価値がある。逆に、一回のプロンプトで完結する要約や分類、単純な API 呼び出しが目的なら、計画エージェントや自己検査エージェントを挟む分だけ構成要素が増え、設定すべき環境変数と確認すべき画面も増える。この場合は公式 SDK を直接呼ぶほうが短い経路になる。

もう一つの境界は Python のバージョンである。Web をソースから動かすだけなら Python 3.10+ で足りるが、SAgents v2 と Desktop v2 は 3.12+ を要求する。社内の標準ランタイムが 3.10 や 3.11 に固定されている環境では、どちらの版を採用するかによって前提が変わる。README の記述だけでは、3.10 環境で v2 系の機能のうち何が使えて何が使えないかは判別できない。ここは曖昧なままだ。

比較対象としての LangGraph: グラフ定義か、製品一式か

同じく複数エージェントの協調を扱う選択肢に LangGraph がある。両者の違いは抽象度の置き場所である。LangGraph はエージェント間の遷移をグラフとして自分で定義し、状態管理やチェックポイントの仕組みを提供する。開発者はノードと辺を書き、実行の制御を自分のコードに持つ。Sage は逆で、Plan、Simple、Fibre、Self-Check という役割分担と AgentFlow の流れがあらかじめ用意されており、利用者はそれを設定して使う側に回る。

この違いは、UI と配布形態の有無にも表れる。Sage には Visual Workbench、デスクトップアプリ、Chrome 拡張、IM 連携が付属し、作業の様子を画面で見る前提になっている。LangGraph はライブラリであり、可視化や配布は利用側が用意する。既存の社内ツールに組み込みたいのか、それとも完成した作業環境が欲しいのかで、選ぶべき側は変わる。なお Sage の README は LangGraph に言及していない。この比較は構成要素の性質に基づく筆者の整理である。

ライセンスと保守: MIT であることの意味と、確認すべき差分

Sage は MIT ライセンスで公開されている。これは商用利用、改変、再配布を許容する条件であり、社内ツールへの組み込みや派生版の配布を妨げる条項は含まれない。ただし MIT は無保証であり、動作の保証やサポート義務を著作者が負うものではない。法的な判断はここでは扱わない。組織として導入する場合は、法務ではなく調達やセキュリティの観点から、依存パッケージの棚卸しを別途行う必要がある。

保守の面で手がかりになるのはリリースの刻み方である。desktop-v1.1.6、v1.1.7、v1.1.8 が 2026-05-26 の同日に並んでおり、デスクトップ版は短い間隔で版を重ねている。一方 README のバージョンバッジは 1.1.0 を指しており、ドキュメントとリリースの対応は一枚岩ではない。導入を決める前に、自分が使う入口（CLI なのかデスクトップなのか）に対応する版と、その版が要求する Python のバージョン、そしてサンドボックスの3モードがどこまで実装されているかを、リポジトリのタグと docs/en/applications/ 配下の各ガイドで突き合わせておきたい。README の記述からは、そこまでの粒度は読み取れない。

編集部の結論

Sage が向くのは、計画から実行までの流れを複数のエージェントに分担させ、その過程をデスクトップや Web のワークベンチで目視したいチームである。逆に、単発の API 呼び出しで足りる用途や、Python 3.12 未満の環境しか用意できない場合は、この構成を選ぶ理由が薄い。導入前に確認すべきは、デスクトップ版が Apple 公証を受けていないため macOS で Gatekeeper の例外操作が必要になる点、SAgents v2 と Desktop v2 が Python 3.12 以上を要求する点、そして既定の LLM 接続先を SAGE_DEFAULT_LLM_API_BASE_URL で自前のエンドポイントに差し替えられるかどうかである。

公式情報源

1. License: MIT
2. Project website
3. README
4. Releases
5. ZHangZHengEric/Sage on GitHub