AI coding agent が小さな変更をするだけなら、問題はたいてい「変更できるか」ではない。「変更の途中状態が、あとで追える形で残っているか」だ。

agent が bug を引き受け、log を読み、task を分け、file を修正し、test を走らせる。途中で model や session が変わったり、別の agent が続きを担当したりすると、最初に失われやすいのは code ではなく process state だ。今の work item は何か、誰が何を済ませたのか、どの step がどの check で止まっているのか、どの task が先に終わる必要があるのか、最終 deliverable は team の約束を満たしているのか。

今日メモしておきたい jpicklyk/task-orchestrator は、この隙間を扱う project だ。新しい agent runtime でも project management SaaS でもない。MCP server として、work item、dependency graph、quality gate、schema enforcement、actor attribution、persistent state を server side に置き、MCP-compatible client が同じ workflow に沿って進むようにする。

2026-07-17 時点で GitHub repository page、README、Releases page、Tags page、公開 commit history、LICENSE、version.properties、local git clone から確認できる公開情報では、jpicklyk/task-orchestrator は 196 stars、22 forks。主言語は Kotlin で、GitHub language breakdown は Kotlin 98.7%、JavaScript 1.2%。license は MIT。公開 Git history の起点は 2025-05-22 19:59:19 UTC、initial commit は 3b257e8。候補取得時の GitHub search が記録した最近 push は 2026-07-16 16:01:27 UTC。default branch main の最新 commit は c91a823、commit time は 2026-07-16 16:01:25 UTC。GitHub Releases の current latest release は v3.11.0 で、release page の公開時刻は 2026-07-15 14:47。対応する tag commit は 2420456、commit time は 2026-07-15 14:11:07 UTC。version.properties の version も 3.11.0 だ。

プロジェクト概要

項目内容
リポジトリjpicklyk/task-orchestrator
位置づけMCP server で AI agent workflow discipline を実行する
Stars196
Forks22
主言語Kotlin
ライセンスMIT
公開 Git history 起点2025-05-22 19:59:19 UTC、initial commit 3b257e8
最近 push2026-07-16 16:01:27 UTC
最新 main commitc91a823、2026-07-16 16:01:25 UTC
Latest GitHub releasev3.11.0、2026-07-15 14:47
version file3.11.0
キーワードMCP、workflow discipline、quality gates、schemas、agent attribution

prompt だけで agent を縛らない

多くの team は今でも、agent を縛る rule を system prompt や AGENTS.md に書いている。まず plan を出す、test を走らせる、verification を飛ばさない、最後に summary を出す。これは有効だが、本質的には soft constraint だ。agent は守ることもあれば忘れることもある。ある session で守っていても、次の session が前の state を知っているとは限らない。

Task Orchestrator の考え方は、その制約を protocol boundary に近づけるものだ。README に出てくる機能には、persistent task storage、task dependencies、quality gates、schema-driven artifacts、actor attribution、context recovery、state audit、search が含まれる。agent は口頭で「終わりました」と言うだけではなく、MCP tool 経由で structured state を提出する。server は current task、dependency、schema を見て、次に進めるかを判断する。

この種の tool の価値は、agent を賢くすることではない。agent が process を崩しにくくすることだ。特に long-running task、multi-session、複数人または複数 agent の collaboration では、単発の回答の美しさより state boundary の方が重要になる。

Quality gate が中心になる

Task Orchestrator でいちばん見たいのは、quality gate を server-enforced な workflow node として扱っている点だ。

普通の todo list は「何をしたか」を残せる。しかし agent workflow でより重要になるのは、「今、次の step に進んでよいか」だ。implementation の前に task decomposition が必要かもしれない。code change の後には test evidence が必要かもしれない。delivery の前には artifact schema を満たす必要があるかもしれない。blocked task を completed にしてはいけないし、dependency を持つ task は前提を飛び越えられない。

README にある schema と gate の仕組みは、このためのものだ。team は agent に、ある step で特定構造の artifact を出すよう求められる。自由作文ではなく、check できる形の state にする。多少の workflow cost は増えるが、recoverable、auditable、machine-checkable な状態が残る。

coding agent にはかなり現実的な話だ。human reviewer は chat log 全体を読みたいわけではない。知りたいのは、この agent がどこを変えたのか、根拠は何か、test evidence はどこか、まだ満たしていない条件は何か、という点だ。これらが server side に構造化されていれば、次に引き継ぐ人や agent は会話ログを掘り返さずに済む。

MCP server という置き場所

これを standalone app ではなく MCP server にすることにも意味がある。

MCP はすでに多くの agent client が tool を接続する共通層になっている。Task Orchestrator がここにいることで、Claude Desktop、Claude Code、Cursor、Windsurf、Copilot、Gemini CLI、自作 agent runner など、複数 client に同じ task state と workflow rule を渡せる。対象は UI ではなく、task state と workflow rule だ。

README から見る限り、project は Kotlin、SQLite、Exposed ORM、Flyway migrations、MCP SDK、Docker image、shell installer、複数 client 向け config example で構成されている。雰囲気としては backend に近い。local または container 上の stateful service が、workflow state の source of truth になる。

これは、約束事を各 agent client の prompt に散らすより安定しやすい。prompt は style、preference、project context を書く場所として残せばよい。task state、dependency、gate result は、もう少し硬い場所に保存した方がよい。

向いている場面

第一の場面は long-running task だ。module migration、cross-file bugfix、security hardening、一連の test 補強などは、途中で context が変わりやすい。Task Orchestrator は、次の session が recoverable な work item を見られるようにする。

第二の場面は multi-agent collaboration だ。ある agent が code search を担当し、別の agent が implementation を担当し、さらに別の agent が verification を担当する。共通 state がなければ、各 agent は別々の world model を持つ。server side の task graph があれば、少なくとも同じ work item set を基準に進められる。

第三の場面は、team が deliverable format を標準化したい場合だ。bugfix には root cause、changed files、test evidence、risk note が必要。refactor には dependency impact と rollback note が必要。こうした要求は、何度も agent に念押しするより schema にした方が安定する。

第四の場面は、agent behavior を audit したい環境だ。actor attribution と state history は code review の代わりにはならないが、「どの agent がいつ何をしたか」をあとで追いやすくする。

注意したいところ

第一に、Task Orchestrator が扱うのは workflow discipline であって security isolation ではない。v3.11.0 release note でも、project-root scoping は collaboration と context partitioning のためのもので、security boundary ではないと説明されている。sandbox として扱うべきではない。

第二に、追加の state を持つ。state がある以上、backup、migration、cleanup、team convention が必要になる。一回限りの小さな task なら、issue や local checklist の方が軽い場合もある。

第三に、schema gate の品質は team design に依存する。schema が広すぎると縛れない。細かすぎると、agent は問題解決より format を満たすことに時間を使う。最初は少数の critical gate から始めるのがよさそうだ。

第四に、project は v3.11.0 と多くの releases を持っているが、AI agent workflow 周辺で速く進化している tool でもある。critical workflow に入れる前に、non-critical repository でしばらく試したい。

まとめ

Task Orchestrator が面白いのは、さらに「よく話す」UI を作るのではなく、AI agent workflow で散らばりやすいものを server side constraint として扱っているところだ。task、dependency、evidence、gate、attribution である。

agent に typo を一つ直させるだけなら、少し重く見えるかもしれない。しかし agent task が session、tool、人をまたぎ始めているなら、jpicklyk/task-orchestrator は観察する価値がある。agent workflow の次の一手は、より長い prompt ではなく、より硬い state machine かもしれない。