Empryo: シンボル単位でコードを編集するグラフ型エージェントの実力と境界

grepと文字列パッチが壊れる理由から出発している

多くのコーディングエージェントは、リポジトリを検索し、ファイル全体を読み、該当箇所を文字列として置換する。READMEはこの方式を「they never know what depends on the code they just changed」と表現している。変更したシンボルを誰がimportしているか、どのファイルが歴史的に一緒に変更されてきたか、変更がどこまで波及するかを、エージェントが把握しないまま編集が進むという指摘だ。Empryoが解こうとしているのはこの一点に絞られる。対象読者は、単一ファイルの修正ではなく、複数ファイルにまたがるリファクタリングやバグ修正をエージェントに任せたい開発者である。リポジトリの構成から見ると、TypeScriptで書かれたCLIとTUI、デスクトップアプリ、そしてシンボル操作を担うコアが分離されている。公開されているのはissue trackerとSoulForgeのソースであり、Empryo本体のソースはこのリポジトリには含まれていない点は先に押さえておきたい。

起動時にtree-sitterでグラフを組み、PageRankとgit共変更で順位づけする

仕組みの中心は「code genome」と呼ばれるライブ依存グラフだ。READMEによれば、起動時にtree-sitterがリポジトリを解析し、シンボル、import、呼び出し箇所をグラフとして構築する。ノードの重要度はPageRankとgitの共変更履歴で順位づけされ、編集前には「blast radius」、つまり何がこのファイルをimportしているか、歴史的に何と一緒に変わってきたか、変更が何段階先まで波及するかが提示される。グラフへの問い合わせはミリ秒単位で返り、LLMトークンを消費しないと記述されている。ここが設計上の要点である。モデルにファイルを読ませて依存関係を推論させるのではなく、決定的な解析結果を先に用意し、モデルには判断だけをさせる。編集側は65以上のシンボル単位操作で構成され、バッチはアトミック、つまり全部成功か全部ロールバックのいずれかになり、最後にtypecheckがゲートとして走る。空白やインデントの揺れでパッチが失敗する問題を、AST操作で回避する狙いが読み取れる。

10のルーティング可能な役割と、タブ単位のモデル割り当て

Empryoは単一モデルのループではなく、役割ごとにモデルを差し替える構成を取る。READMEに列挙されている役割はbrain、spark（scout）、ember（code）、explore、verify（review）、goal review、desloppify、summarize、compact、web searchの10種類で、22のプロバイダから任意のモデルを各席に割り当てられる。設定はグローバルまたはプロジェクト単位で行い、ワークスペースのタブごとに上書きできる。あるタブではフロンティアモデルにコードを書かせ、別のタブでは安価なモデルにissueのトリアージをさせ、さらに別のタブではローカルモデルをプライベートリポジトリに当てる、という使い分けが想定されている。サブエージェントは親のプロンプトキャッシュ行を継承するため、同じコンテキストの再送がキャッシュ読み込み料金で済むと説明されている。コストはモデル別、サブエージェント別、タブ別、セッション別、日別に追跡される。役割を増やせば安くなるわけではなく、安いモデルに探索させて高いモデルに書かせる、という分担の設計だと理解するのが正確だろう。

インストールはempryo.comのスクリプト経由のみ

導入は公式サイトのインストーラに限定されている。macOSとLinuxでは curl -fsSL https://empryo.com/install.sh | bash、WindowsのPowerShellでは irm https://empryo.com/install.ps1 | iex を実行する。READMEはHomebrew、WinGet、npmでは配布していないと明記し、GitHub Releasesや第三者のパッケージマネージャからバイナリを取得しないよう警告している。APIキーの設定は empryo --set-key anthropic sk-ant-... のように行い、Ollamaを使う場合はキー不要でローカル実行できる。プロジェクトのディレクトリに移動して empryo を実行すると起動する。デスクトップアプリとビルド済みバイナリはempryo.com/downloadから取得し、macOS、Linux、Windowsで動作する。LSPはMason経由で576以上の言語サーバーを利用でき、任意のMCPサーバーと13のライフサイクルフックに対応する。SoulForgeからの移行を考える場合、SoulForgeは brew tap proxysoul/tap && brew install soulforge、または bun install -g @proxysoul/soulforge で今も導入できるが、新機能の開発はEmpryo側に移っている。

ベンチマークの数字は自社比較であり、条件を自分で確認する必要がある

READMEはpiとの比較を2ラウンド分掲載している。ラウンド1は3つのバグと3モデル、ラウンド2はhono、zod、kyの実際のバグ5件を対象とする。修正数は8/9対7/9、7/10対6/10、コストは28%低い1.13ドル対1.58ドル、23%低い7.08ドル対9.19ドル、実時間は57%速い4分16秒対10分、32%速い22分30秒対32分55秒、効率は入力トークンが5.7倍少ない1.09M対6.21M、ステップ数が28%少ない274対382と記載されている。ラウンド2は学習カットオフ後のマージ済みPRから実バグを取得し、履歴を消去し、各実行後に回帰テストを注入したと説明されている。方法論とトランスクリプトはempryo.com/benchmarksに、再現用リポジトリはproxysoul/pi-vs-empryo-benchに置かれている。ここで注意すべきは、比較相手も計測も同じベンダーが用意したものであり、第三者の追試ではないという点だ。数字を採用判断の根拠にするなら、再現リポジトリで自分のリポジトリに近いタスクを回すべきである。

向かない場面と、SoulForgeという現実的な選択肢

この設計が過剰になる場面は明確だ。依存関係がほとんど無い単一ファイルのスクリプトや、設定ファイルの修正が中心の作業では、グラフ構築のコストが便益を上回る可能性がある。また、実行できるバイナリが社内で監査済みのものに限られる環境では、公式インストーラスクリプトをcurlでパイプ実行する方式自体が承認を通らない。エアギャップ環境も同様だ。代替としてREADMEが挙げているのはSoulForgeで、これはEmpryoの前身にあたる。同じシンボル単位、グラフ型のエージェントだが、デスクトップアプリ、高速化されたエンジン、composableなコアを備えた再構築版がEmpryoであり、SoulForgeはバグと重大な問題の修正のみを継続する。つまり両者の違いは機能の有無ではなく、開発の活発さと配布形態にある。Homebrewやbun経由で導入したい、既存のSoulForgeワークフローを変えたくない、という理由でSoulForgeに留まる判断は成立する。ただし新機能は期待できない。

ライセンスと保守コストの見取り図

リポジトリのライセンスはNOASSERTIONと表示されており、GitHubが既知のライセンスとして認識していない。READMEはSoulForgeのソースが既存のライセンスの下でここにアーカイブされていると述べ、LICENSEファイルを参照するよう促している。Empryo本体は無料と書かれているが、これは価格の記述であって、ソースの利用条件ではない。法人で導入する場合は、リポジトリのLICENSEを直接読み、必要なら法務に確認する必要がある。保守の観点では、リリースがv2.20.23からv2.20.25まで2026年7月に集中しており、その後9月にもpushがある。パッチ番号が細かく進む傾向は、修正が高頻度で入る反面、APIや設定キーの安定性を前提にしにくいことを示唆する。CIに組み込むなら、headless CLIのバージョンを固定し、更新時に--set-keyで設定した認証情報とルーティング設定が維持されるかを確認する運用が現実的だ。

編集部の結論

既存のgrep型エージェントで大きなリポジトリのコンテキスト消費に悩んでいるチーム、特にTypeScript以外の言語が混在するモノレポを扱うチームには試す価値がある。逆に、依存関係がほぼ無い小規模スクリプトや、監査済みバイナリしか実行できない環境には向かない。導入前に確認すべきは、配布チャネルがempryo.comのみである点、ライセンスがNOASSERTION表記でリポジトリのLICENSEを直接読む必要がある点、そしてベンチマークが自社リポジトリproxysoul/pi-vs-empryo-benchで再現可能とされている点だ。この3つを確認せずに本番ワークフローへ組み込むべきではない。

公式情報源

1. Issues
2. Project website
3. proxysoul/Empryo on GitHub
4. README
5. Releases