Amenbo

Amenbo 自身の開発は、AI のセッションを2〜3本、同時に走らせている。ぶつかるのはファイルとタスクの2つ。ファイルは git worktree でタスクごとに分け、タスクは todo からしか通らない予約で分ける。その回し方を、実際の事例として書く。

CLI と GUI は別プロセスとして、同じ store.sqlite を同時に書く。それでも壊れないのは、各書き込みを丸ごと1トランザクションにして SQLite に直列化させ、失敗したら丸ごと巻き戻すから。変更は change_feed に1行残り、GUI のウォッチャがカーソルで変わったぶんだけ読み直して画面に映す。

複数のプロジェクトを扱うと、AI は隣の文脈を拾って記憶を汚す。プロンプトで「触らないで」と頼んでも守られる保証はない。Amenbo は .amenbo でプロジェクトに束ね、外へ手を伸ばす操作を CLI 自体が out_of_reach で断る。お願いではなく、仕組みで区切る話。

第1回で「探索が約2倍軽い」と実測し、第2回で「ストアはグラフ」と示した。今回はその読み方。タスクに追いつくときは、つながった数件だけを索引でたどる（O(result)）。着手できるか・決定が現行かといった状態は保存せず、エッジからその場で導出する。だから一覧・カード・着手ガードがズレない。

AI エージェントのためのタスク管理 Amenbo の作りを、個別技術に入る前にざっと見渡す。GUI と CLI が同じ Rust の Core を呼び、データはローカルの単一 SQLite に入る。プロジェクトのフォルダは目印だけを持ち、ストアはタスクと決定のグラフになっている。

Amenbo という、AI エージェントのためのタスク管理アプリをリリースしました。第 1 回は、なぜこれをつくったのか。AI エージェントを使い込むほど壊れていく文脈の問題と、人間のタスク管理とは分けて、ローカルの閉じた環境に置くという棲み分けの話です。