AI coding agent はコードを書く力を増していますが、「いま何をしているか」を保ち続けるのはまだ苦手です。長いタスクでは、計画がチャット、仮の markdown、GitHub Issues、TODO コメント、端末出力に分散しがちです。コンテキストが圧縮されたり、別の agent に引き継いだりすると、多くの状態が失われます。

今日紹介する kenn-io/kata は、この状態管理の層を小さく切り出したツールです。Go 製の local-first issue tracker で、AI agent には安定した CLI と JSON 出力を、人間には TUI による閲覧、整理、編集、監督の画面を提供します。GitHub の現在の表示では、およそ 211 stars、12 forks、主な言語は Go、ライセンスは MIT。現時点では GitHub Releases は公開されていません。

プロジェクト概要

項目内容
リポジトリkenn-io/kata
Stars約 211
Forks12
主な言語Go
ライセンスMIT
作成日2026 年 4 月 30 日
状態early public preview
ReleaseGitHub Releases はまだなし

project management ではなく、タスク状態の層

kata の README は、スコープをかなり狭く定義しています。これは完全な project management suite でも、git workflow engine でも、agent worker pool でもありません。むしろ、人間と agent の両方が理解できる durable task ledger です。

この境界は重要です。多くのチームにはすでに GitHub Issues、Linear、Jira、あるいは markdown の計画があります。kata はそれらを直接置き換えるより、ローカル作業セッションで agent が必要とする構造化された状態を扱います。タスク、判断、リンク、コメント、状態変化を、チャットだけに閉じ込めないための場所です。

「agent にチャットで覚えてもらう」より、この形は復元しやすいです。agent は既存 issue を検索して重複を避けられます。作成時に idempotency key を付けられます。読み書きには JSON を使えます。close するときには、完了の根拠を書かせることができます。長時間、多ラウンド、多 agent のローカル開発では、こうした制約が効きます。

アーキテクチャ: local daemon と SQLite

kata の設計は明確です。タスクデータはリポジトリの履歴に直接入れず、KATA_HOME 配下のローカル SQLite データベースに置きます。その前に長時間動く daemon があり、CLI と TUI はそこへ接続します。リポジトリ側には、workspace を kata project に結びつける小さな .kata.toml だけを置きます。secret は含みません。

この設計にはいくつかの効果があります。

第一に、コードリポジトリをきれいに保てます。issue 履歴が code commit と混ざらず、branch ごとに別々のタスクデータベースが現れることもありません。

第二に、複数の checkout や worktree が同じ local kata project を共有できます。同じ project を指す .kata.toml があれば、同じ issue ledger を見ます。

第三に、Git ではない workspace でも使えます。kata は git remote から project 名を推測できますが、状態そのものは Git object や remote sync に依存しません。

一方で、代償もあります。現在の標準形は local-first であり、git push だけでチームに自然共有されるものではありません。README では将来の authenticated shared server mode に触れていますが、現在の local daemon を public network や信頼できない LAN に公開するべきではありません。

CLI は agent 向け、TUI は人間向け

kata には二つの入口があります。

agent 向けの入口は CLI です。代表的な流れは次のようになります。

kata init
kata create "fix login race" --body "Safari can double-submit the callback."
kata list
kata show abc4
kata comment abc4 --body "Reproduced on macOS."
kata close abc4 --done --message "Fixed; verified tests pass." --commit <sha>

README は agent workflow をかなり意識しています。作成前に検索する、既存 issue を優先して更新する、解析が必要なときは --json を使う、project を暗黙に作らない、本当に完了したときだけ close する。どれも基本的ですが、agent が失敗しやすい部分です。

人間向けの入口は kata tui です。人は JSON を直接読まなくても、agent が残した work item、コメント、関係、close の根拠を確認できます。この組み合わせは現実的です。agent API だけでは、人間が重複、雑な close、間違った関係を確認する摩擦が大きくなります。

issue relationship と close の制約

kata は parent、blocks、blocked-by、related といった関係を扱えます。create や edit の時点で追加できます。

kata create "add auth callback" --parent abc4 --blocks d4ex
kata edit abc4 --related f9aa

これは単なる TODO list より有用です。大きな作業を子 issue に分けられます。blocking relationship は、agent にどちらを先に進めるべきかを伝えます。related は順序ではなく、補助的な文脈を残します。

close の扱いも重要です。README では、daemon が構造的に危険な close を拒否すると説明されています。たとえば、未完了の子 issue がある parent を close することや、短時間に多くの sibling issue をまとめて close することです。また、--message、--commit、--test、--reviewed、--evidence などで、何をもって完了とするかを明示できます。

これは形式的な厳しさではありません。agent は「コードを変更した」ことを「タスクが完了した」と誤認しがちです。kata は close action を明示的にすることで、その雑な終わり方を減らそうとしています。

event stream、digest、backup

kata の状態変化は durable events として残ります。CLI から event を読んだり、tail したりできます。

kata events --after 0 --limit 100 --json
kata events --tail

これは長時間動く agent にとって、復元ポイントになります。次のセッションは、チャットの記憶だけに頼らず、event cursor から再開できます。kata digest は、ある時間範囲の activity を actor ごとにまとめ、誰が何を作成し、コメントし、close し、label 変更したかを確認できます。

backup には kata export と kata import があります。export は JSONL を生成し、import はそこから新しい database を再構築します。JSONL は読みやすく、diff しやすく、private backup repository にも置きやすい形式です。ただし、現在の import は既存 database に一部 project を増分 merge するものではありません。災害復旧や移行には便利ですが、チーム同期の仕組みとして使うものではありません。

Beads や git-bug との違い

README では、kata、Beads、git-bug の違いも説明されています。

Beads は分散 graph issue tracker に近く、デフォルトでは project 内に .beads/ の Dolt database を作ります。branch、merge、push/pull、server mode、agent workflow などを重視します。git-bug はさらに git-native で、issue、comment、identity を Git object として保存し、通常の Git remote で同期します。

kata は別の選択をしています。状態は user-local service に置き、リポジトリには .kata.toml binding だけを置きます。コードと一緒に自然配布される性質は弱くなりますが、複雑さは小さく、repository footprint もかなり軽くなります。

task state をリポジトリと一緒に流したいなら、git-bug や Beads のほうが合うかもしれません。一方、ローカルの agent task ledger が欲しく、タスク database を code history に入れたくないなら、kata の設計はかなり素直です。

インストールと現在の境界

kata は単一の Go binary で、README では macOS、Linux、Windows を対象にしています。ただし、pre-built release binaries はまだ公開されていません。現在の主な導入方法は source install です。

go install github.com/wesm/kata/cmd/kata@latest

clone して build することもできます。Windows なら次のような形です。

go build -o kata.exe ./cmd/kata

導入前に、いくつかの境界を見ておくべきです。

  • プロジェクトは early public preview で、command contract や UI detail は変わる可能性があります。
  • GitHub Releases がまだないため、チームで使うなら commit や module version を固定したほうがよいです。
  • default local daemon には authentication がなく、信頼できない network へ公開するべきではありません。
  • team shared mode は将来の計画で、現在は個人または同一マシン上の agent workflow 向けです。
  • 状態は Git に入らないため、マシン移行前には kata export が必要です。

これらは試用を妨げるものではありません。ただし、すぐにチーム唯一の issue system として使うより、慎重に導入する段階のツールです。

向いている人

kata は次のような開発者に向いています。

  • Claude Code、Codex、Gemini CLI、OpenCode などに継続的な作業を任せる人。
  • agent 用の構造化された local task layer が欲しい人。
  • 複数の worktree や checkout で同じ local task state を共有したい人。
  • TUI で agent の task、comment、close evidence を確認したい人。
  • GitHub Issues や Linear は重すぎるが、普通の TODO では軽すぎる個人 project maintainer。

すでに成熟した issue system があり、agent がたまに小さな修正をするだけなら、kata は過剰かもしれません。しかし複数の agent session と日常的に協作しているなら、local task ledger はかなり実用的な基盤になります。

まとめ

kenn-io/kata は、AI coding workflow の具体的な弱点を扱っています。コードは agent が書けても、タスク状態をチャットだけに置くのは弱い。kata は local daemon、SQLite、CLI、TUI、event stream、JSONL backup を組み合わせ、人間と agent の間に監査しやすい task ledger を置きます。

良い点は、スコープが控えめなことです。issue tracking、project management、agent scheduling、Git sync を一つの大きな仕組みにまとめるのではなく、まず「local task state を読み書きでき、復元できる」ことに集中しています。AI agent workflow を本気で整えたい開発者なら、追っておきたいプロジェクトです。

リポジトリ：https://github.com/kenn-io/kata