「作業用グループチャットでAgentを呼び出す」
PromaのREADMEに載っていた次の言葉が特に印象に残っている：
「最もシームレスな汎用Agent体験をワークフローにもたらし、100xプロフェッショナルユーザーのために作られた未来のプロダクトが、今まさにプロアクティブAgentの段階を実現しようとしている。」
これはGitHub上でよく見かける「また一つのAgentフレームワーク」ではない。Promaの開発者であるErlichLiu氏は、非常に現実的なアプローチを取っている。Agentの能力を、中国人にとって最も馴染みのある作業環境である飛書のグループチャットに直接組み込んだのだ。
新しいAgentプラットフォームを開く必要も、専用画面に切り替える必要もない。飛書のグループチャットでメンション（@）を送るだけで、Agentは動き出す。
なぜ飛書なのか？
この選択の背後には、非常に強いロジックが存在する。
現在市場に出回っているAI Agentツールの大半は「スタンドアロンアプリケーション」として提供されている――コードを書くならCursorを開き、チャットにはClaudeを使い、ドキュメント整理はNotion AIで行う。それぞれのツールが独自のインターフェースとワークフローを持っているのだ。
しかし現実として、中国のナレッジワーカーの日常業務のほとんどは飛書上で行われている。 コミュニケーション、ドキュメント、会議、承認、プロジェクト管理――すべてがこのプラットフォーム内で完結する。Agentが飛書内で使えないのであれば、それはユーザーの日常業務から「隔離」されているのと同じだ。
Promaの賢いところはここだ。ユーザーに習慣を変えさせようとするのではなく、Agentをユーザーが既に持っている習慣の中にねじ込んだ点にある。
技術アーキテクチャ：単なる飛書ボットではない
単なる飛書ボットを作るだけなら、Promaに特筆すべき点はない。しかし、そのアーキテクチャははるかに複雑だ。
Claude Agent SDK をベースに
Promaの基盤にはAnthropicのClaude Agent SDKが採用されている。これは、Claude Agentのコア機能であるマルチステップ推論、ツール呼び出し、自律的な計画立案を継承していることを意味する。
複数モデルプロバイダーのサポート
Claude SDKをベースとしつつも、PromaはAnthropicにロックインされない。任意の大規模言語モデルプロバイダーに柔軟に接続できるのだ。OpenAI、Google、国内の大規模モデルプラットフォームでも問題ない。これは非常に現実的な設計であり、特に国内のネットワーク環境において、複数プロバイダー対応は高い可用性の保証につながる。
Electron デスクトップアプリ
PromaにはElectron製のデスクトップクライアントが存在し、これにより次のような機能が実現している。
- ローカルファイルへのアクセス――AgentがPC上のファイルを直接読み書き可能
- システムレベルの統合――システムコマンドの呼び出しやローカルツールへのアクセスが可能
- オフラインキャッシュ――一部の機能をオフライン状態でも利用可能
直近のコミット（4時間前）では「ディスク管理の非同期化＋ファイル監視の高頻度ディレクトリフィルタリング、超大規模ワークスペースでのUIフリーズ修正」が行われている。これは、作者が大規模利用シナリオにおけるパフォーマンス課題に真摯に取り組んでいる証拠だ。
プロアクティブAgentの段階へ
Promaは「受動的応答」から「能動的実行」へ進化を遂げつつある。これは、Agentが質問されたときだけ答えるのではなく、次のようなことが可能になることを意味する。
- プロジェクト状態の能動的な監視
- 異常検知時の自動通知
- コンテキストに応じたワークフローの自動トリガー
837スターに込められた取り組み
現在、Promaのスター数は837個――決して多いとは言えないが、開発段階とコミュニティの質を考慮すれば、健全な数字だ。
145のブランチ、844回のコミット、52のタグ――個人主導のプロジェクトとしては、このイテレーション速度は非常に目覚ましい。さらに注目すべきは、リポジトリの構造が非常に明確であることだ。
apps/electron――デスクトップクライアントpackages――コア機能パッケージproma-thinking――Agent推論モジュールdocs――ドキュメントrelease-notes――リリースノートtutorial――チュートリアル
これは作者が実験的な玩具を作っているのではなく、本気でプロダクトを構築していることを示している。
誰に向いているのか？
Promaが最も適しているのは次のようなユーザーだ。
- 飛書のヘビーユーザー――チームの日常業務がすべて飛書上で完結しており、AI機能をシームレスに統合したい場合
- 中国の開発者――国内の大規模モデルプロバイダーへの接続が必要だが、国際モデルへのアクセスも維持したい場合
- 100xプロフェッショナルユーザー――単なるQ&Aではなく、複雑なマルチステップタスクの処理をAgentに任せたい場合
- Agentインフラを自前で構築したいチーム――サードパーティ製SaaSプラットフォームへの依存を避けたい場合
直面する課題
Promaもいくつかの現実的な課題に直面している。
エコシステムへのロックインリスク。 複数モデルプロバイダーをサポートしているものの、コアアーキテクチャはClaude Agent SDKに深く依存している。AnthropicがSDKの戦略や課金モデルを変更した場合、影響を受ける可能性がある。
飛書APIの制約。 飛書ボットの機能は飛書オープンプラットフォームのAPIに制限されるため、一部のシステムレベルの操作はグループチャット環境内で完了できない可能性がある。
コミュニティ規模。 現状、コアコントリビューターはErlichLiu氏一人に集中している。健全なプロジェクトとしてリスクを分散するには、より多くのコミュニティ参加者が必要となる。
競合プラットフォームの台頭。 国内ではAgentプラットフォームが急速に登場しており、ByteDanceのCoze、Alibabaの百煉（Bailian）、Tencentの元器（Yuanqi）はいずれも飛書やWeCom（企業微信）との統合ソリューションを備えている。Promaは独自の差別化ポジショニングを確立する必要がある。
Promaの価値は技術的なブレイクスルーにあるのではなく、正しい切入点を選んだ点にある。つまり、ユーザーが既に日常的に利用している場所でAgentを稼働させるというアプローチだ。この発想はシンプルに見えるかもしれないが、Agentツールが「百花繚乱ではあるが、それぞれが孤立して戦っている」現在においては、むしろ最も希少で価値のあるものだ。