Keyoku - agent の操作履歴を再利用できる MCP workflow に変える
Coding agent を日常的に使っていると、摩擦になるのは「model が code を書けるか」だけではありません。同じ repository で、毎回似たような流れを説明することがあります。どの check を走らせるか、どの context file を読むか、変更内容をどうまとめるか、どの段階で human review を挟むか。個人では記憶に散らばり、team では agent が直接使える形にしにくい知識です。
今日紹介する Keyoku-ai/keyoku は、この問題に向けた small tool です。TypeScript 製の CLI / MCP server で、Claude Code、Cursor、Codex の local activity tracing、pattern detection、workflow execution を担います。README では、agent の操作を観察し、繰り返し pattern を学習し、それを one-command の MCP-native workflow に変える tool と説明されています。
公開時点の GitHub search result では、約 20 stars、5 forks。主な言語は TypeScript、license は MIT、作成日は 2026-03-10 で、最近も更新されています。Repository tag と npm registry では、現在の package version は 2.0.2 です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | Keyoku-ai/keyoku |
| 位置づけ | Local activity tracing、workflow discovery、MCP execution layer |
| Stars | 約 20 |
| Forks | 5 |
| 主な言語 | TypeScript |
| License | MIT |
| Current version | 2.0.2 |
記録するのは結果だけではなく過程
多くの agent-assisted development tool は、context retrieval や code generation に重点を置きます。Keyoku の入口はもう少し process layer にあります。Hooks を通じて agent の tool call を記録します。Bash、Edit、Write、Read、MCP call などを lightweight な activity event として保存します。Default state directory は ~/.keyoku で、README は cloud も telemetry もなく、record、template、execution history は local に置かれると説明しています。
これは、static documentation にはしにくいが何度も出てくる作業に向いています。たとえば、同じ repository を修正するたびに一連の check を走らせ、特定の convention file を読み、change summary を作り、human confirmation の後で deploy する、といった流れです。一度や二度なら prompt で済みますが、何度も繰り返すなら audit できる workflow にした方がよい。
Keyoku の狙いは、agent にすべてを自動化させることではありません。「今やったこと」を replay 可能で review 可能な template に変えることです。この boundary は重要です。Development workflow には shell で直接走らせてよい step、agent の判断が必要な step、人が止めて確認すべき step が混ざっているからです。
過去 session から繰り返し workflow を掘り出す
Install は単純です。
npm install -g keyoku
keyoku initkeyoku init は MCP server を Claude Code に登録します。~/.codex がある場合は Codex の config.toml にも MCP server を追加します。README では、keyoku import によって Claude Code と Codex の過去 transcript から activity を backfill できるとも説明されています。Install 直後に sample がない cold start を減らすためです。
Workflow discovery は workflow_suggest で起動します。Keyoku はまず heuristic で最近の activity から recurring sequence を探します。Non-overlapping counting、noise suppression、longest-chain collapsing のような処理です。GEMINI_API_KEY または ANTHROPIC_API_KEY を設定している場合は、小さな model が draft を refine します。偶然の一致を落とし、名前を整え、run ごとに変わる値を {{placeholders}} にできます。
この設計は cost boundary がわかりやすいです。Base discovery は model に依存せず、model は draft を maintainable template に近づける部分だけに使われます。大きな coding task は、普段使っている coding agent に任せる形です。
Approval が trust boundary になる
Keyoku は、見つけた sequence をそのまま automation script にする tool ではありません。README では approval が強調されています。Candidate workflow は workflow_approve で保存され、template は ~/.keyoku/templates.json に入ります。Shell script を review するように、step を確認してから approve する必要があります。
Execution では、template の step に複数の type があります。
bash: 指定されたcwdと timeout で command を実行し、output を記録する。agent_prompt: 実行を一時停止し、その step を coding agent に渡し、execution_completeで続行する。human_review: 明示的に human confirmation を待つ。
これは単純な shell script generation より agent workflow に向いています。Test failure 後の判断、review comment への対応、deploy 前の最終確認は、ただの command list に押し込むべきではない場面が多いからです。
MCP tools は template、knowledge、goal まで含む
Keyoku は複数の MCP tools を公開します。中心は activity と workflow 管理です。activity_record / activity_list、workflow_suggest、workflow_capture、workflow_approve、workflow_execute、execution_list などがあります。
それ以外にも、knowledge_submit / knowledge_query のような context layer、goal_create / goal_assess のような goal checking tool があります。README では connector 系の tool も説明されており、外部 MCP server をつなぎ、autonomy gating で呼び出しを制御できます。
そのため Keyoku は、単なる command history tool というより local agent workflow runtime に近い存在です。「どの command を実行したか」だけでなく、どの経験を knowledge として残すか、どの goal に machine-checkable な success criteria を持たせるか、どの external call に approval が必要かまで扱おうとしています。
Codex / Claude Code の横に置く layer
Keyoku の面白いところは、Codex、Claude Code、Cursor を置き換えようとしていない点です。むしろ、それらの横に置く local memory と workflow layer です。Agent がどう操作したかを記録し、再利用できる pattern を見つけ、MCP tool として agent に返します。
これは複数 project を持つ人に向いています。Repository ごとに test command、deploy command、review habit、context file が違います。毎回 prompt で説明するより、一部の flow を activity log から捕まえ、approve された template にして、次回 agent が提案できる形にする方が保守しやすい。
ただし、新しい security surface も生まれます。Template の bash step は自分の権限で実行されます。External connector は実サービスに触れる可能性があります。Keyoku の approval model は boundary を作りますが、template review の代わりにはなりません。Install 前に repository の SECURITY.md を読み、まず low-risk repository で試すのがよいです。
まとめ
Keyoku-ai/keyoku はまだ早期の tool ですが、方向性ははっきりしています。Coding agent の local operation を記録し、繰り返し workflow を見つけ、それを MCP 経由で承認可能かつ実行可能な template にします。
Claude Code、Cursor、Codex で同じ project flow を何度も説明しているなら、Keyoku は見る価値があります。Code generation そのものを改善する tool ではありません。むしろ「一度きりの prompt を、どうやって再利用できる operation asset に変えるか」を扱う tool です。複数 repository を長期的にメンテナンスする人には、この layer の方がもう一つの prompt snippet より役立つ場面があります。