なぜツリー？

なぜツリーなのか

AI が作るのは、意図したものではなく「AI が理解したもの」です。そのズレはコードができてからしか見えず、気づくのが遅いほど直すコストは膨らみます。ズレを広げるのは2つ — 一度に大きな塊で送ること、そして何が抜けているのか気づけない、べた書きのテキストです。

よくある回避策

どの回避策も、結局は同じ壁にぶつかる

どれも役に立ちます。ただ、構造化・送信・進捗・検証という一連の流れの一部しかカバーできず、残りは記憶と手作業に委ねられます。

✓ 手軽でいつでも参照でき、規約やルールを書いておくには最適。

△ ただ、数ターンで AI がそのルールを無視し始め、べた書きのテキストには構造がないため、抜けた要件は製品から抜け落ちて初めて気づきます。

✓ コードを書く前に、AI にまず計画を立ててもらえる。

△ ただ、その計画は意図ではなく AI の解釈にすぎず、途中で止めて確認する間もなく一気に実行され、セッションと共に消えます — 来週になれば、どこまでやったかの痕跡は残っていません。

✓ 受け渡し前に、要件をしっかり構造化できる。

△ ただ、渡してしまえば、あとは自力です — spec に対してどこまで進んだかは追えず、出来上がっていく全体像を一目で見る手段もありません。

ツリーという答え

要件には階層があります — ログイン・新規登録・パスワード再設定は、どれも「認証」の下にぶら下がります。べた書きのリストでは頭の中で構造を組み立て直すしかありませんが、ツリーなら空いた枝がそのまま見えます。抜けを見つけるのが、考える作業ではなく、見るだけの作業になります。

一度に送る塊が大きいほど、AI の解釈がずれる余地も大きくなります。ノードは機能ひとつ分 — 正確に理解できる小ささで、できたそばからすぐ確認できます。

各ノードは、実装中・テスト中・完了のいずれか。どこまで確認できているかは、チャット履歴を掘り返さなくても一目で分かります。

計画はセッションと共に消えますが、ツリーは記録として残ります。1週間後に戻ってきても、自分もエージェントも、今どこにいるのかがすぐ分かります。

ベータ期間中は無料 · Mac・Windows・Linux