Factorly - AI agent の tool call に local runtime を挟む
AI agent が実際の workflow に入り始めると、問題は「model が code を書けるか」だけではなくなります。どの tool を呼べるのか、どの credential に触れるのか、失敗時に log が残るのか、同じ call を繰り返して暴走しないのか。GitHub token、Linear key、Slack webhook、deploy script、local command をそのまま agent に渡すと、短期的には楽ですが、長期的には permission boundary が曖昧になります。
今日紹介する factorly-dev/factorly は、その間に入る local layer です。MCP server、REST API、CLI command をいったん Factorly 経由にし、agent には承認済みの tool surface を見せます。Factorly は local encrypted vault から credential を注入し、governance rule を適用し、audit log を残し、tool を test / manage する UI も提供します。GitHub page では現在およそ 19 stars、0 forks。主な言語は Go、license は GPL-3.0 です。Repository は 2026 年 4 月 3 日に作成され、2026 年 5 月 28 日にも更新されています。Release page では最新 version は v0.17.2、公開日は 2026 年 5 月 27 日です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | factorly-dev/factorly |
| Stars | 約 19 |
| Forks | 0 |
| 主な言語 | Go |
| ライセンス | GPL-3.0 |
| 作成日 | 2026 年 4 月 3 日 |
| 最近の更新 | 2026 年 5 月 28 日 |
| 最新 release | v0.17.2 |
Agent は tool を見るが、secret を直接見ない
Factorly で一番重要な設計は、tool capability と credential material を分けることです。Agent は Factorly に接続すると、configured tools、workflow、returned data を見られます。しかし API key、token、credential は local vault に残り、実際の call 時に Factorly が注入します。
これは token を agent config や environment variable に直接置くより扱いやすいです。Agent は GITHUB_TOKEN の実値を知る必要がありません。承認済みの github.* tool を呼び、Factorly が vault reference を解決し、実 request を投げ、結果だけを返します。すべての risk が消えるわけではありませんが、credential の露出面は各 agent prompt や tool context ではなく local runtime に寄せられます。
Team にとっても boundary を説明しやすくなります。人間が tool definition と vault を管理し、agent は approved interface を使う。問題が起きた場合は audit log で、誰がいつどの tool を呼び、どの params を渡し、policy に止められたかを確認できます。
MCP、REST、CLI を一つの config にまとめる
Agent tool chain は、たいてい複数の interface を混ぜます。既存の MCP server、internal REST API、local CLI command です。Factorly はそのうち一つだけを扱うのではなく、同じ config と call layer にまとめようとします。
README によると install path は広く、Homebrew、npm、pip、go install を選べます。初期化後、blueprint を import し、tool を設定し、credential を vault に保存し、factorly sync で Claude Code、Cursor、Codex と接続します。Agent 側からは Factorly が single MCP server または CLI entry point に見えます。一方で、人間は裏側の tool を protocol ごとに管理できます。
この unified layer の価値は fragmentation を減らすことです。Factorly がない場合、MCP server config、REST token、shell command allowlist、各 tool の log、agent ごとの接続設定を別々に面倒見ることになります。Factorly は少なくともそれらを project-local な control plane に寄せます。
Blueprint はよく使う service の接続を軽くする
最近の README では、Factorly は 40 以上の blueprint を含むと説明されています。対象には GitHub、Slack、Stripe、Linear、Gmail、Notion、Jira、HubSpot、Salesforce などがあります。Blueprint の意味は数の多さではなく、「SaaS を agent tool にする」作業を手書き YAML から import + credential 設定に近づけることです。
たとえば GitHub の場合、agent は issue を読む、PR を確認する、comment する、release を列挙する、といった操作を求められます。それぞれ endpoint、params、auth、response filtering が必要です。Project ごとにゼロから書くと、命名の揺れ、緩い validation、token exposure、読みにくい log が起きやすいです。
Blueprint は出発点です。Common service の tool surface を導入し、そのあと local project に合わせて policy を締める。Permission decision を代わりにしてくれるわけではありませんが、tool definition を作る反復作業を減らします。
Workflow は agent call を governable step にする
Factorly は単体 tool だけでなく workflow も扱います。Workflow は複数 tool を deterministic な順序でつなぎ、variable passing、conditional branching、state persistence、per-step policy を持てます。Agent から見ると、一つの workflow call が自由な連続 tool call の代わりになります。
Deploy、publish、data sync のような操作では特に効きます。Agent に「test の前に deploy しないで」と毎回頼むより、workflow に順序を書いたほうが堅いです。Test が失敗したら write operation に進まない、特定 step だけ confirmation を要求する、といった条件を runtime layer で止められます。
つまり、natural language の「慎重にやって」という制約の一部を、実行可能な tool pipeline に移します。AI coding agent では、この種の deterministic pipeline は system prompt を一行増やすより信頼しやすいことが多いです。
Policy、rate limit、audit が中心にある
Factorly の governance layer には deny、confirm、rate limit、loop detection、dangerous command blocking があります。README では、write / delete 系 template が default で confirmation を求め、built-in tool が破壊的 shell command や database delete pattern を止めると説明されています。
これは完全な sandbox ではありません。Factorly は local runtime であり、最終的には user が tool、credential、実行環境をどう設定するかに依存します。それでも「agent を完全に信じる」よりは良い buffer になります。Call を拒否でき、write operation に人間の確認を挟め、同一 call の繰り返しを検出でき、失敗や block を log に残せます。
Audit log は特に重要です。Agent tool call の失敗は後から追いにくいです。どの issue を見たのか、どの request を送ったのか、どんな response を受けたのか、なぜ何度も retry したのか。Factorly は call を記録し、UI と CLI で history、filter、replay を提供します。長時間動く agent や team project では、chat log を掘るより復元しやすいです。
Output compression と UI は実用面を見ている
Tool output が多すぎることも agent workflow のよくある問題です。npm test、terraform plan、API list call は context を大量に消費しますが、signal は少ないことがあります。Factorly の docs では、JSON、log、common command output を compress、deduplicate、filter、head/tail truncate し、削減量を audit log に記録すると説明されています。
これは「tool を接続する」だけではなく、agent が tool を使うときの context cost を見ている設計です。Tool call の返り値が noisy すぎると agent は重要な情報を見落としやすいです。短すぎると debug clue が消えます。Factorly はその調整を runtime layer に置こうとしています。
Web UI も同じ方向です。Tools、workflows、vault、blueprints、history などの page があり、人間が先に tool を試し、params と response を確認してから agent に渡せます。この「test first, then expose to agent」という流れは、sensitive operation では直接 agent config に追加するより安全です。
v0.17.2 は audit experience を磨いている
最新 release v0.17.2 の changelog は、history と audit log pagination が中心です。/history の pagination、/history/more endpoint、filter 後の windowing、cursor-based pagination、workflow group を page boundary で分断しない処理が追加されています。
派手な feature ではありませんが、Factorly の目的には合っています。Agent tool runtime で audit history がすぐ重くなり、filter が現在 page だけを見て、workflow call が pagination で分裂するなら、復盤はかなり辛くなります。v0.17.2 がこの部分を直しているのは、実際の log size と readability を意識しているということです。
その前の v0.17.0 や v0.16.0 でも、vault reference、dashboard、workflow、store まわりの改善が続いています。Stars は少ないですが、release cadence はかなり速く、最近はほぼ毎日のように version が進んでいます。
向いている場面
Factorly は、AI agent に実際の tool を呼ばせ始めた人に向いています。Local で数行の code completion をするだけなら、少し大きすぎるかもしれません。
典型的には次のような場面です。
- MCP server、REST API、CLI command を統一して agent に渡したい。
- GitHub、Linear、Slack などの token を agent に直接見せたくない。
- Write、delete、deploy operation に confirmation や deny rule を付けたい。
- Agent tool call をすべて audit log に残し、後で復盤したい。
- Multi-step operation を workflow にし、agent の自由な command chaining を減らしたい。
- UI で tool を試してから Claude Code、Cursor、Codex に sync したい。
もし agent の使い方が code suggestion 程度なら、Factorly は過剰です。価値が出るのは、agent が operations や business tools に入ってきた段階です。
注意したい境界
Factorly は cloud IAM でも強い isolation sandbox でもありません。Credential exposure を減らし、policy と audit を足せますが、user が tool、vault、runtime を正しく設定する必要があります。High-permission token を vault に入れても、tool definition が広すぎれば、agent は allowed interface 経由で危険な操作を実行できます。
GPL-3.0 license も商用組み込みでは確認が必要です。Local development tool として使うだけなら扱いやすい場合が多いですが、自分の product や service に組み込むなら license obligation を先に見るべきです。
Project はまだ若く、stars と forks も少ないです。Large agent platform と同じ成熟度を期待するより、まず低リスクの service や read-only internal API から試し、vault、logs、policy、UI が自分の workflow に合うか確認してから permission を広げるのが現実的です。
まとめ
factorly-dev/factorly の価値は、agent tool call には local control layer が必要だと割り切っているところです。Prompt だけですべての security と governance を解決しようとせず、credential、policy、workflow、output compression、audit log を runtime に置いています。
Coding agent が「code を書く assistant」から「issue を調べ、test を走らせ、request を送り、script を実行する operator」へ近づくほど、この中間層は重要になります。Factorly はまだ小さい project ですが、方向は明確です。Agent に tool を使わせつつ、人間が credential boundary、operation rule、reviewable log を持ち続けるための runtime です。