はじめに
自分宛ての「これやっといて」は、Slack のメンション、DM、メール、アラート、口頭……と、あちこちに散らばって降ってくる。拾い落とすし、拾えても文脈を毎回載せ直すのがしんどい。「今やるべきこと」が機械可読な形で一箇所に集まっていない、というのがずっと不満だった。
最近これを、自作のターミナルタスク管理ツール taskdog を「単一ハブ」に据えて、Claude Code の /loop で巡回させる形で回している。まだ全然固まっていないし、後述するとおり落とし穴もいくつも踏んだ。ただ、方向性としてはかなり良い手応えがあるので、途中経過をメモしておく。
taskloop ── 外部イベントを一箇所に集めて巡回する
やっていることを一言でいうと、外部イベント源（Slack など）を taskdog という単一ハブに集約して、/loop で「取り込み → トリアージ → 実行可否判定 → 直列 dispatch」を回す、というだけだ。人間が握るのは判定ゲートだけで、拾い上げと着手は自走させたい。仮に taskloop と呼んでいる。
taskdog はもともと「キーボードだけで回すターミナルのタスク管理ツール」として作っていたもので、スケジュール最適化と依存グラフを持っている。今回はこれを、単なるタスク管理ではなく agent オーケストレーションのイベントバスとして使っているのがミソだ。
Claude Code 側は、大きな1個の賢いスキルにせず、薄い規約型のスキルに割った：
- 取り込み：Slack の自分宛てを巡回して、自分がやるべき依頼だけを taskdog 化する。相槌・共有・確認応答は 👍 リアクションで受領して握りつぶし、タスクにはしない。
- 判定：各タスクを「agent が自走してよいか」で3値に判定する（
dispatch/human/unclear）。除外だけタグを付け、全件 note に判定理由を1行残す。 - 自走：
dispatch可のものを1件だけ agent に投げ、start → 進捗ログ追記 → 完了条件を満たしたら complete、という作法で完遂させる。
1個ずつが薄いので、/loop で回したときに挙動を読みやすい。
設計の肝：watermark を持たず taskdog の状態だけを正にする
巡回ループを書くとき、つい「どこまで処理したか」のカーソル（watermark）を別に持ちたくなる。今回はあえて持たないことにした。
各ループは「その依頼がもう taskdog にあるか？」だけで重複を弾く。状態の正は taskdog に一元化して、ループのほうは薄い巡回器に保つ。差分検出のために Slack の permalink とタスクを突き合わせ、確実な抜けだけを note 付きで足す。カーソルを二重管理して壊れるより、ハブの状態を唯一の真実にしたほうが、少なくとも今のところは素直だった。
（なぜ taskdog を vault ではなく専用ストアに置くのか、という所有権の話は前に別記事で書いた。taskloop はその「専用ストア」を自走ループの中枢に据える使い方にあたる。）
実際に回してみた
ある日、Slack の自分宛てを全チャンネルぶんざらって、既存の taskdog タスクと permalink で突き合わせ、抜けているものだけを note 付きで足す、というのをやった。そのあと /loop の dynamic mode（間隔をモデルに任せるモード）で放置したところ、約5時間、無人で「新着依頼なし」を確認し続けながら、拾ったものを随時タスク化できた。取りこぼしを気にせず他の作業に集中できたのは、素直に良かった。
判定ゲートのほうも機能した。同僚から来た実依頼はタスク化して dispatch 判定、客先連携に関する問い合わせは「これは人間が答えるやつ」として human 判定＋除外タグ＋理由 note、という具合に、種類の違う依頼で判定が繰り返し効いた。危険な操作・客先への送信・書き込みを伴うステップは、必ず一旦止めて人間の承認を挟む。ゲートは人間、実行は agent、という境界をループの外に置いているぶん、自走と安全が両立できている。
踏んだ落とし穴
ここからが正直パート。良かった話だけ書いても仕方ないので、踏んだやつを並べる。
1. watermark を持たない設計は空巡回を生む
さっき「あえて watermark を持たない」と書いたが、これは諸刃だった。処理済み・見送り済み・👍受領済みのメッセージが再ヒットし続ける。間隔を10分に緩めても、既処理の再ヒットだけの空振り巡回が終日続いた。「taskdog にあるか」だけでは、“タスク化しないと判断したもの” を弾けないのが原因だ。処理済み判定に「見送り済み・受領済み・タスク化済みを除外」を足すか、平穏が N 回続いたら自動で間引くか、どちらかの補正が要る。ここはまだ直している最中。
2. 判定だけして着手しないと候補が滞留する
判定スキルを回して dispatch 可の候補を溜めるところまではできても、着手を手動待ちにすると、ループが拾っても誰も手をつけないまま溜まる。判定と着手を切らさず繋ぐか、滞留した候補を定期的に人間が捌くか、どちらかを決めておかないと「判定だけは進むのに前に進まない」状態になる。
3. 完了判定が甘いと「note を書いて終わり」に逃げる
一番効いた失敗がこれ。agent は、完了条件を満たしていないのに調査ログだけ note に残して、タスクを開いたまま放置することがある。あるタスクで、調査自体は終わっているのに note 更新止まりで状態が進まない、というのが実際に起きた。原因は2つで、① タスクの粒度が粗くて「完了」の線が引けない、② 完了判定が実行側の主観に委ねられている。対策は、タスクを完了判定可能な粒度に分割し、完了条件をタスク生成時に明文化しておくこと。相手ボール待ちは「完了」ではなく pause に落とす運用と併せて、「開いたまま進まない」をゼロにしにいく。
4. 次の1件を選ぶ基準が不透明
dispatch ループが、実行可能なタスクの中からどれを次にやるのかが人間から見えない。優先度・依存・締切・見積りのどれで並んでいるのかが表に出ていないと、「なぜそのタスクが今なのか」を説明できず、自走を信頼しきれない。判定スキルが判定理由を1行残すのと同じ作法を、選定にも適用する ── 選んだ理由も1行 note に残す、というのが今の方針だ。
まとめ、と、これから
- 人間の Inbox は方々に散る。単一ハブ（taskdog）に集約すれば「今やるべきこと」が機械可読な1箇所に集まり、判定ゲートさえ守れば実行を安全に自動化できる。
- ただし自走を信頼に足るものにするには、**〈完了判定可能な粒度へのタスク分割〉と〈次の1件の選定基準の可視化〉**が要る。これが無いと、ループは回るのに「開いたまま進まない／なぜ今それなのか説明できない」状態になる。
/loopはセッションを閉じると止まる揮発ループなので、長時間の安定は確認できても常時稼働ではない。次は cloud スケジューラに移して、セッション終了後も止まらない常設巡回にしたい。
繰り返すが、これはまだ試行錯誤の途中で、正解を配っているつもりはない。ただ「散らばった依頼を単一ハブに集めて、判定ゲートだけ握って残りを巡回で自走させる」という形は、手応えとしてかなり良い。もし似たことをやっている人がいたら、空巡回と完了判定をどう畳んでいるか聞いてみたい。taskdog 自体は GitHub で公開しているので、興味があれば覗いてみてほしい。