Amenbo の全体像

シリーズ・第 2 回 — 「AI エージェントのためのタスク管理をつくる」。前回はなぜつくったのか。今回は、その中身をどう組み立てたかの全体像です。

前回は「なぜ」でした。今回は「どう組み立てたか」を、個別の技術に入る前に、まず全体をざっと見ておきます。細かいところは次回以降で一つずつ掘ります。

一枚岩の Core に、2つの入口

Amenbo（https://amenbo.work/）の中身、つまり業務ロジックは、Rust の Core（amenbo-core） に全部あります。人が使う GUI（React・Tauri） と、人と AI が打つ CLI（amenbo） は、その薄い皮。両方が、同じ Core の関数を呼びます。

だから、どちらから足した機能も、同じ1つの実装に乗ります。中央サーバーはありません。

データは、フォルダでなくアプリ領域に

意外かもしれませんが、プロジェクトのフォルダにデータは入っていません。あるのは .amenbo という小さな目印だけで、中身はどのプロジェクトかを指す番号（project_id）だけです。

実体は、OS のアプリデータ領域にある単一の store.sqlite。設定や表示名は別ファイルにあり、そこも秘密は持ちません。1つのストアを、複数のフォルダから指せます。

ストアは、タスクと決定のグラフ

その store.sqlite の中身は、ばらばらの表ではなくグラフです。第 1 回で触れた「決定とタスクのつながり」が、そのままデータの形になっています。

• タスクと決定が、2種類のノード。
• 決定どうしは supersede などで、決定とタスクはリンクで、タスクどうしは依存で——それぞれエッジでつながります。

前回「どのレコードを、どういう関係で読むか」と言ったのは、この構造のことです。

この先、どこを掘るか

ここまでが全体像です。次回からは、その一部にズームインしていきます。たとえば——

• 第 3 回：なぜ、追いつくのが速いのか
• AI の活動範囲を .amenbo で区切るしくみ
• GUI と CLI が同じ SQLite を同時に触っても壊れない理由

まずは、「どこに何があるか」だけ頭に入れておいてください。