なぜ、追いつくのが速いのか

シリーズ・第 3 回 — 「AI エージェントのためのタスク管理をつくる」。前回は全体像でした。今回は、そのグラフの読み方です。

第 1 回で「探索が約 2 倍軽い」と実測し、第 2 回で「ストアはグラフ」と示しました。今回は、その読み方 —— なぜ軽いのかを見ます。

エッジをたどるだけ

あるタスクに追いつくとき、Amenbo（https://amenbo.work/）が読むのは、そのタスク本体と、つながった数件だけです。前提になった決定、いま止めているブロッカー、コメント。どれもタスクの番号から、索引で一発でたどれます。

ストア全体をなめて回すことはありません。だから、ストアが何千件・何万件に育っても、1件に追いつく手間は変わらない —— つながった数件ぶんのままです。第 1 回で測った「約 2 倍軽い」の正体は、この読み方にあります。

状態は、保存せず導出する

「このタスクは着手できる（ready）か」「この決定はまだ現行か」——こうした状態を、Amenbo は列に保存していません。読むたびに、エッジからその場で導出します。

• 着手できる＝ブロッカーが残っておらず、前提の決定がまだ現行。
• 決定が現行＝それを supersede する新しい決定が、まだ無い。

保存しない理由は、ズレを生まないためです。もし「着手できる」を保存したら、依存や決定が変わるたびに、一覧・カード・着手ガードのすべてを更新して回らないといけない。導出なら、判定は 1 か所。同じ判定をみんなが使うので、「一覧では着手できそうなのに、いざ着手するとブロックされる」が起きません。

次回

第 4 回：AI の活動範囲を、構造で区切る です。プロンプトのお願いではなく、.amenbo を境界に「読めない・書けない」を仕組みでつくる話をします。