AI エージェントのためのタスク管理をつくった
シリーズ・第 1 回 — 「AI エージェントのためのタスク管理をつくる」。Amenbo という小さなアプリを、どう考えて、どう組み立てたか。今回はその出発点、「なぜつくったのか」から始めます。
Amenbo（https://amenbo.work/）という、AI エージェントのためのタスク管理アプリをリリースしました。
普通のタスク管理アプリと違うのは、主に使うのが AI エージェントで、人間はその次だというところです。第 1 回は、機能の紹介の前に、そもそもなぜこういうものをつくったのかを書きます。
使い込むほど、文脈が壊れていく
AI エージェントで開発をしていると、規模が大きくなるほど、長く続くほど、同じところでつまずきます。文脈が膨らみ、どう対処しても行き詰まる。
対処に困るだけではありません。作業そのものの土台も崩れていきます。
- 意思決定の流れが切れる。 「何を・なぜそう決めたか」の積み重ねが、途中で途切れる。
- 依存関係をプロンプトで抱えきれない。 タスクの前後関係や、その元になった決定を、会話の中だけで管理するのは無理があります。
- 別プロジェクトの情報がノイズになる。 関係ない文脈が混ざると、それ自体が AI の記憶を汚します。
プロバイダー側も、内部に人間の知らないメモを残す機能で補おうとしていますが、それはそれで別の問題を抱えています。
文脈に追いつくコストを抑える
この手詰まりに効くのが、今回つくった Amenbo です。AI エージェントのために、人間との議論で
- 何が決まったのか（決定）
- それに紐づくタスクは何か
- 決定とタスクのつながり
を記録します。肝は、そこを探し直さずに追える構造にしたところにあります。決定・タスク・依存は、ばらばらのメモではなく、つながったグラフになっています。
「この作業は何を前提に、何が決まって、いま何で止まっているのか」——それを、履歴を総ざらいせずに、このつながりから引けます。
どれくらい違うのか、同じ問いを Amenbo あり／なしの2条件でエージェントに解かせ、手数と読み込んだ量を実際に計ってみました。
劇的な差ではありません。どちらでも、最後は正しい答えにたどり着きます。違うのは、そこまでにかかる手間と、読む量です。今回試したのは、履歴もコミットもよく整った、Amenbo なしでも追いやすい部類のコードでした。それでも、探索は約 2 倍。整理が甘いコードなら、差はもっと開くはずです。
Amenbo がとくに効くのは、この2つです。
- 探索が、際限なく膨らまない。
エッジをたどるので、読むのは関係する数件で済みます。
勘でコードを追うと、外したときに総当たりが延々と続きます。 - 「いま何で止まっているか」がわかる。
どのタスクが、どの依存でブロックされているか。
これは今この瞬間の状態で、コードにも git 履歴にも残りません。
ただ、Amenbo が助けてくれるのは「どのレコードを、どういう関係で読むか」まで。そのレコードを読む手間そのものは、これまでどおり残ります。
検証の方法と、生の数字（クリックで開く）
検証パターン（同一モデル claude-sonnet-5 のヘッドレス実行・各 n=4・中央値で比較）
- 自分の開発バックログにある実タスク由来の2つの問いを使用（テーマ：配布方式／DB 接続層の方針）。
- 問いは Amenbo を匂わせない中立文で、両条件とも同一：(1) 何に決まったか、(2) なぜ／何を変え・撤去したか、(3) いまどこまで進んでいるか。
- 条件A（なし）：
Read / Grep / Glob / gitのみ。amenboは遮断し、ソースと git 履歴だけで解く。 - 条件B（あり）：上に
amenboCLI を追加。実ストアのクローンを読ませ（本番は無傷）、使い方の学習コストは除外（定常状態）。 - モデル・プロンプトは両条件で同一。エラー・1ターン退化・サブエージェント委任の run は集計から除外。外部メモリ注入や文脈の持ち越しも遮断。
- 採取：ツール呼び出し回数／読み込んだバイト数／ターン数／コスト。
テーマ1：配布方式（中央値 ［最小–最大］）
| 指標 | なし (A) | あり (B) | 倍率 |
|---|---|---|---|
| ツール呼び出し | 18.0 [14–23] | 8.5 [8–14] | ×2.1 |
| 読み込み量 (KB) | 41.4 | 29.1 | ×1.4 |
| ターン数 | 19.0 | 9.5 | ×2.0 |
| コスト (USD) | 0.40 | 0.31 | ×1.3 |
テーマ2：DB 接続層（中央値 ［最小–最大］）
| 指標 | なし (A) | あり (B) | 倍率 |
|---|---|---|---|
| ツール呼び出し | 19.5 [19–33] | 10.5 [8–12] | ×1.9 |
| 読み込み量 (KB) | 29.9 | 16.2 | ×1.9 |
| ターン数 | 20.5 | 11.5 | ×1.8 |
| コスト (USD) | 0.50 | 0.29 | ×1.7 |
手数のばらつきも違う：あり (B) は 8–14 に収束、なし (A) は 14–33 と広い。当てを外すと総当たりが際限なく膨らむ、ということ。両条件とも最終的な答えは正しかった。
責任を負うのは人間
では、これをどこで動かすか。ここでもう一つ、動かしがたい力学が効いてきます。AI は責任を取れない、ということです。
どれだけ AI エージェントを使っても、その成果物の責任は人間が負います。仕事の上では、人間の名前で出すしかありません。
だから AI エージェントは、手元の閉じた環境で動いたほうがいい場面が出てきます。実際、私自身のタスク管理は Asana などを使って、私の責任のもとで関係者とやりとりしています。ここに AI が入ってくると、困る。
だから、分ける
答えは、棲み分けでした。
人間が責任を持ってやりとりする本物のタスク管理は、そのまま人間の側に置く。文脈のためにつくった Amenbo は、AI 専用のローカルの閉じた環境に置く。こうすれば、ちょうどいい棲み分けが成り立ちます。
これが Amenbo です。人間のタスク管理と競合しない、AI エージェントのためのタスク管理。
チーム向けの仕組みとは、競合しない
世の中には、チームで AI を活用するための仕組みもたくさんあります。Amenbo は、それらと競合しません。向き合っている課題が、そもそも違うからです。
次回
第 2 回：Amenbo の全体像 です。GUI ⇄ Tauri ⇄ Core ⇄ CLI のレイヤー構成と、データがどこに置かれるか、決定とタスクをどうグラフとして持つかを、図でまとめています。個別の技術に入る前に、まず全体を見渡してください。