2026-10-08

4週間くらい"next.dシステム"と読んで運用している、割と良いので解説を生成した

AIエージェントが会話をまたいで作業していると、「何がまだ終わっていないか」をどこに置くかが問題になる

会話が終わると文脈は消える

作業ログの末尾に「残件」と書いても、それは書いた時点の記録で、今の状態ではない

後から読んだAIが古い残件を「今も未決」と読み違える

そこで、未完了の作業だけを一件一ファイルにしたフォルダ next.d/ を作った

2026-09-11 に作業ログ log.d/ と同時に作った

まずそもそも論として「LLM Wikiのlog.mdはみんなが1つのファイルを書きにきてコンフリクト起きがちだけど、目的は追記なんだからファイルを分けたらいいよね」という発想で、ログを1枚のファイルではなくフォルダの中の1件1ファイルにした。前からErgonシステムで使っていた

自宅マシンに包括的LLM Wikiを作って運用し始めてしばらく経ったところで、複数の開発プロジェクトが同居していることで「次に何をするんだっけ」の管理の必要性を感じ、「log.dみたいにnext.dを作ればいいんじゃないか」と思ってやってみた

一件一ファイルにすると、複数のエージェントが同時に書いても無関係な項目同士はぶつからない

5つの欄

目的：何を達成するための残件か

現状と根拠：日付つきの観測と、その出典。未確認の範囲も書く

待ち条件：何が揃えば動けるか（人の確認、指示、情報）

次の操作：再開したら最初にやる具体的な一手

完了条件：何をどの証拠で確かめたら閉じてよいか

待ちの種類を1語で付ける

human（人の観測や回答を待つ）／instruction（着手や範囲の指示を待つ）／agent（書いた条件でAIが進められる）

これは担当者や実行許可ではない。agent と書いてあっても、今このAIが着手してよいとは限らない

閉じるときは closed/ に移し、日付・理由・証拠を書く

完了と打ち切りを区別する

例：「方針変更で別の評価に統合。元の課題の検証が完了したわけではない」

これ全然人間が設計してない、この解説を見て初めて知ったw

経緯と知識 → wiki（根拠に合わせて書き直す）

起きた出来事 → log.d（一件ずつ足す。訂正も新しい記録として足す）

未完了と待ち条件 → next.d（今の状態に書き換え、理由を付けて閉じる）

今の資源量や応答 → 必要なときに測り直す

次にやることの一覧表は next.d から毎回生成する。一覧ファイルを別に持つと正本が2つになる

運用の実績（2026-10-08 時点）

期間は約4週間。書式を固めて検査ツールを入れたのは 09-26 なので、その形ではまだ2週間に満たない

開いている項目 97件、閉じた項目 55件

開いている項目は 62件(09-26) → 80件(09-29) → 97件(10-08) と増え続けている

閉じ忘れが見つかった

「未配布」として残っていた項目が、実際には配布済みだった

調べ直さずに再開できた

次の操作と完了条件が書いてあったので、前回の調査をやり直さずに作業を始められた

なぜ止まっているのか、なぜ閉じたのかが文章で残る

ここがいちばんはっきり効いている

次の作業を選ぶのが速くなったかは測っていない

長い目で見た閉じ忘れや重複の割合も測っていない

欄が埋まっていることは、内容が正しいことの証明ではない

開く速さに閉じる速さが追いついていない

たかだか97件溜まっていることは深刻ではない

急いでやる必要があるタスクは即座に着手しているので、このリストは基本的には「確かにやった方がいいけど今やらなくていいな」と人間が判断したもの

止まった理由をきちんと書けることが、止まる口実にもなる

例：横断監査で本当の食い違いを14件見つけたのに、「別の機械のセッションを待つ」と台帳に書いて手が止まった

次に測るなら、週ごとに開いた件数と閉じた件数、それに開いている項目の古さの分布

ファイル中心の作業で、会話をまたいで根拠と状態を引き継ぎたいとき

すでに Issue tracker で通知・担当・権限が回っているなら、二重管理になる理由を先に考えるべき