AI エージェントのタスク依存関係を人間の頭で管理しない方法

スキーマを変える仕事と、その上に API を足す仕事。どちらも未着手だったので、私たちは 2 本のセッションに同時に渡した。30 分後、API 側がカラム名を自分で決めて実装を終えていた。スキーマ側は別の名前で作っていた。diff がぶつかって、私たちは片方を捨てた。

API 側に渡した指示に「スキーマが先」とは書いていなかった。書いてあったのは私たちの頭の中だけだ。

先に終わっていないと始められない仕事がある、というだけの話だ。スキーマ、API、画面。順番はある。ただ、その順番がどこにも保存されていない。あるのは書いた人の記憶と、そのときのプロンプトの文面だけ。

「A が終わったら B を頼む」を人が覚えている限り、次を配る係はその人になる。AI が速くなるほど配る回数は増える。夜中に終わったカードの次は、朝まで誰も取らない。

試した順に書く。どれも途中までは使えた。

最初は私たちも 1 本のセッションに全部書いた。「まずスキーマ、通ったら API、最後に画面」。これは確実に効く。1 本で終わる範囲なら今でもこうする。ただ 2 本に分けた瞬間、順番はどちらのプロンプトにも載らない。

番号付きの TODO リストも作った。1 2 3 と並べれば人間には読める。AI は 3 を先にやっても止められない。番号は順番の希望で、制約にはならなかった。

GitHub Issues に「blocked by #12」と書くのもやった。残るし、番号で呼べるし、別の AI にも読ませられる。困ったのは #12 を閉じたあとだ。#13 が解放されたことに誰も気づかない。人がコメント欄を見に行くまで #13 は寝ている。

ボードの列 (Todo / Doing / Blocked) も試した。列は状態を持てるので、止まっていることは分かる。分からないのは何を待っているか。Blocked に 7 枚あるとき、今日解けたのがどれかは 1 枚ずつ開いて確かめることになる。

最後は自分たちで配った。終わった通知を見て、次を渡す。これが一番正確だった。正確だが、人が寝ている時間と会議中は止まる。

どの対処でも、順番を書く場所自体には困らなかった。プロンプトの文面、リストの並び、Issue のコメント、列の名前、人の記憶。どこかには残る。頭の中に置いた分だけは別の AI に読ませられないが、それ以外は読める。

全部が同じところで止まった。前提が満たされた瞬間に後ろを解放する仕組みがない。解放はいつも、人が見に行って気づくところから始まる。並列に動かせる本数が増えると、その見回りの回数だけが増えた。

大きい案件は、ChatGPT と話したあとに「これの最小タスクを入れて」と頼んで割っている。割るのは AI のほうが速い。出てくるのは 5〜10 枚くらい。この枚数は私たちの典型で、測った値ではない。

困るのは割ったあとだった。10 枚のうち今すぐ触れるのは 2 枚か 3 枚で、残りは何かを待っている。どれが今触れる 2 枚なのかを知っているのは、割った直後の私たちだけだ。翌日にはもう分からない。

私たちは自分のプロダクトと受託を合わせて 3〜4 本のプロジェクトを同じ日に行き来している。プロジェクトごとに「次はこれ」を思い出し直すのは、普通に無理だった。

粒度でも痛い目を見た。「認証まわりを直す」くらいのカードは 1 セッションで終わらない。終わらないカードを前提に置くと、後ろが全部長く止まる。逆に細かく割りすぎると前提の数だけが増えて、自分でも読まなくなった。今は 1 セッションで終わる大きさを基準にしている。これも経験則だ。

欲しかったのは 3 つだった。前提を仕事そのものに書けること。おかしな前提はツール側で拒否されること。前提が終わったら人を通さずに解けること。

だから前提は 1 箇所にだけ保存して、「着手していいか」は保存しないことにした。毎回その前提から導く。着手可否を保存すると、必ずどこかでズレて、ズレたことに気づかない。

1. 1後に来る仕事に「これは dz12 が終わってから」と一言添える。指定できるのは同じプロジェクトのカードで、番号でそのまま書ける。1 枚あたり 20 件まで。
2. 2付けられない形は保存時に弾かれる。自分自身、存在しない番号、輪になる指定 (A が B を待ち B が A を待つ)。プロジェクトに属さない Inbox のカードは前提を持てない。
3. 3前提が満たされたと見なすのは、前提カードの状態が「完了」になったときだけ。アーカイブ済みも満たされた扱いにする。片付けたカードが見えないまま後ろを止め続けるほうが困る。
4. 4セッションを起こすときは「着手できるものからやって」と言う。AI は、前提が全部終わっていて誰も手を付けていないものだけを取ってくる。着手済み、人が止めたもの、前提待ち、前提が見つからないものは別の束で返るので、間違えて取ることはない。
5. 5今すぐ着手できる束に入ったカードは互いに独立している。だから束ごと別のセッションに同時に渡してよい。どれを並列にしていいかを人が見分けない。
6. 6人が止めたカードは、前提が解けても着手できる束には戻らない。止まったまま残る。依存が解けたことを理由に AI が人の判断を上書きしない。
7. 7画面では順路ビューに 3 段で並ぶ。進行中 / 並列可能 / 前提待ち。前提待ちのカードには「前提 dz12」のように、待っている番号がそのまま出る。

セッションに「並列可能なものをまとめて」と言えば、その束だけが出てくる。ここで私たちは配る係から外れた。

夜中に前提が終わって、次のカードが朝まで寝ていることがなくなった。セッション側が着手できるものを聞けば、自分で次に入れる。

同じカードを 2 本に渡す事故は減った。着手できるものとして返ってくるカードは互いに独立なので、まとめて渡してもぶつからない。その束に入っていない 1 枚を手で渡せば、今でも同じ事故は起こせる。

「次はこれ」を覚える仕事が減った。覚える場所がカードの上に移ったので、プロジェクトを行き来しても前提を思い出し直さなくていい。これは計測していない。体感。

解けていないことも書く。依存は人が書いた前提の分しか効かない。書き忘れた前提は誰も教えてくれないし、ツールも拒否しない。拒否できるのは循環や存在しない番号のような形の誤りだけだ。プロジェクトをまたぐ依存は張れない。Inbox のカードは前提を持てないので、順番のある仕事は先にプロジェクトへ移す。それから、今すぐ着手できるというだけで重要とは限らない。どれを先にやるかの判断は人に残っている。1 枚が 1 セッションで終わらない大きさなら、依存を付けても前提待ちが長くなるだけだった。