最近、Codexへ任せる仕事が増えた。
記事を書く。WordPressを直す。公開後の確認をする。開発を進める。別の担当へレビューを渡す。
一つずつなら、会話の中で管理できると思っていた。
でも、複数のタスクが同時に動き始めると、急に分からなくなった。
終わったのはどれか。
hideの確認を待っているのはどれか。
修正は済んだのか。
その判断は、どの会話に残っているのか。
問題は、AIが賢くないことではなかった。
タスクの現在地を、会話の中へ置きすぎていたことだった。
そこで自分は、Task Control Roomというprivateな管理画面を作り、タスクの唯一の正本にした。
この記事は、AIエージェントのタスク管理を会話ログから切り離し、何を一か所へ集め、何を分けたのかを残しておく記録です。
AIエージェントが増えるほど、会話はタスク管理にならなくなった
Codexの会話には、その仕事を進めるための文脈が入っている。
依頼、調査、途中の判断、失敗、修正、完了報告。
作業の流れを追うには、とても役に立つ。
ただ、会話は「今、何を優先するか」を一覧する場所ではない。
三つの仕事が動けば、三つの会話を開く。
別の担当へ渡せば、handoff先の会話も増える。
公開を待つ記事、レビュー待ちの変更、外部サービスの返答待ちが混ざると、未完了だけを拾う作業が必要になる。
最初は、各会話の最後に次の一手を書けば足りると思っていた。
実際には、その次の一手が更新されるたびに、古い完了報告や古い前提も残る。
どの発言が現在有効なのかを判断するために、また会話を読む。
AIへ仕事を任せているのに、人間が会話を巡回して状態を集め直していた。
ここが最初の違和感だった。
Obsidianとメモを増やしても、正本は決まらなかった
次に、ObsidianのDaily noteやMarkdownのタスク一覧へ状態を残した。
会話より一覧しやすい。
前日の記録も引き継げる。
仕様や判断を長く残す場所として、Markdownは今も使っている。
でも、タスク管理では複製が問題になった。
同じ仕事が、会話、Daily note、記事候補一覧、リポジトリのdocsに存在する。
一つをDONEへ変えても、別の場所では未完了のまま残る。
翌朝の引き継ぎを自動化すると、古い状態まで次の日へ運ばれる。
情報が足りないのではない。
同じ意味の情報が多すぎた。
そこで、用途を分けた。
日時が決まった予定はCalendar。
実際の作業と相談はCodex。
仕様、判断理由、検証結果はリポジトリのdocs。
そして、タスク、優先度、担当、待ち、完了はTask Control Roomだけに置く。
Obsidianはタスクの入口から外し、旧一覧も更新しない。
同期を増やすのではなく、正本を一つに減らした。
Task Control Roomを、タスクの唯一の正本にした
Task Control Roomは、自分の事業運用に合わせて作ったprivateな画面です。
CodexやOpenAIの公式機能ではない。
Codexは仕事を実行する側で、Task Control Roomは何を実行するか、何が待ちかを決める側に置いている。
ボードは、P0、P1、WAIT、DONEの四つに分けた。
- P0: 今日進めるもの
- P1: 次に進めるもの
- WAIT: hideの判断、別担当、外部反映などを待つもの
- DONE: 今日完了したもの
増やしすぎないことも決めた。
DONEは永続的な実績一覧ではなく、その日に終わったことを確認する場所。
完了記録や公開結果は必要なdocsへ残し、タスクボードは現在の判断へ戻す。
この形にしてから、AIへ渡す指示が短くなった。
「会話を全部読んで次を考える」ではなく、「このタスクの現在地と完了条件を確認する」から始められる。
AIの性能が上がったわけではない。
古い前提を読ませる量と、迷う場所が減った。
カードには、担当と次の一手が分かる情報だけを置く
一つのカードへ何でも保存すると、Task Control Room自体が長い会話ログになる。
それでは同じ失敗を繰り返す。
カードに置くのは、タイトル、担当、優先度、期限、状態、短いメモ、子タスク。
メモは作業ログ全文ではなく、判断理由と次の一手を短く残す。
子タスクは、完了条件を小さく分けるために使う。
たとえば記事制作なら、構成、本文、公開前QAを分ける。
「記事を作る」という大きな依頼だけより、どこで止まっているかが見える。
一方で、本文や調査結果までカードへ複製しない。
原稿と検証記録はdocs、公開状態はWordPressが正本になる。
ここで大事なのは、すべてを一つのデータベースへ入れることではない。
同じ情報の正本を二つ作らないことだった。
Company画面は、仕事を増やす監視画面にしない
タスクが増えると、次は「誰が動いているか」を見たくなった。
そこでCompany画面を作り、複数のAI担当を部署ごとに並べた。
ただ、これは実プロセスの監視ではない。
AIが何token使っているか、今この瞬間に何を生成しているかも表示しない。
通常作業を担当するAIが、開始、待ち、完了という状態変化の時だけ、短いmetadataを報告する。
一定時間、新しい報告がなければ「観測待ち」へ戻す。
古いworkingを、現在も動いているようには見せない。
Companyは正確な処理量を見せる画面ではなく、担当と直近状態を見渡す補助面にした。
見える化は、細かくするほど正確になるとは限らない。
観測のために新しい仕事を起こすと、管理の方が本体より重くなる。
稼働確認のための定期実行が、AIの仕事を増やしてしまった
ここは、実際に失敗した。
最初は、Companyの状態を新しく保つため、専用の定期実行で各AIの稼働を確認しようとした。
でも、その確認自体が新しいCodexタスクを作り、同じ確認が重なり、tokenも使う。
仕事を減らすための画面が、観測する仕事を増やしていた。
しかも、定期確認で分かるのは「最後に見た状態」にすぎない。
長い作業が続いているのか、すでに終わって報告だけ古いのかを、外側から完全には判断できない。
この方式はやめた。
heartbeatや巡回タスクを作らず、通常作業をしている担当自身が、状態が変わった時だけ報告する形へ移した。
当初はログイン済みChromeを通して報告していたが、ブラウザ接続に依存すると、稼働表示のためだけに画面状態を確保する必要が出る。
現在は、共通のlocal helperからowner-only APIへmetadataだけを一件送る。
認証値をAIへ見せず、画面も開かず、ほかの担当の状態も変更しない。
監視を高機能にしたのではない。
報告経路を小さくし、失敗しても本来の仕事を止めないようにした。
すべてを承認制にすると、人間がボトルネックになった
もう一つの失敗は、AIの操作へ細かく承認を挟みすぎたことだった。
安全を考えると、毎回hideが確認する方が安心に見える。
ただ、状態変更、並び替え、メモ更新まで一件ずつ止めると、hideは承認通知を処理する人になる。
AIへ任せた分だけ、確認作業が増える。
そこで、操作を三段階に分けた。
- Green: 事前に決めた範囲内の状態更新や同一タスクの冪等な更新
- Amber: 複数変更や公開前文面など、差分をまとめて一度確認するもの
- Red: 公開、削除、認証、費用、収益設定など、明示判断が必要なもの
何でも自動化するための分類ではない。
人が見るべき差分を、例外と高リスク操作へ絞るための分類です。
正常な更新は記録だけ残す。
競合、失敗、待ち、範囲外だけを目立たせる。
これで、承認が安全装置として働きやすくなった。
AIのタスク管理は、五つの項目から小さく始められる
Task Control Roomと同じ画面を作る必要はない。
自分の運用で必要だったのは、次の五つだった。
- タスク: 何を終わらせるのか
- 担当: 人、AI、レビュー担当の誰が持つのか
- 状態: 進行中、待ち、完了のどこか
- 根拠: 判断や完了を何で確認するのか
- 次の一手: 次に誰が何をするのか
最初はスプレッドシートでも、小さなボードでもいい。
大切なのは、会話を検索しないと現在地が分からない状態をやめること。
そして、正本を決めたら別の一覧へ自動同期しすぎない。
予定、作業、仕様、タスクは役割を分ける。
AIには、正本の現在状態と、その仕事に必要な根拠だけを渡す。
まとめ。AIが迷わない運用面を先に作る
Codexへ任せる仕事を増やす時、自分はモデルの性能や指示の書き方を先に考えていた。
でも、複数のAIエージェントを事業運用へ入れると、別の問題が出てくる。
どれを進めるのか。
何を待っているのか。
誰が確認するのか。
何を根拠に完了とするのか。
これが会話ごとに分かれていると、AIが賢くても迷う。
人間も、会話を巡回して状態を集め直すことになる。
自分の結論は、AI活用のタスク管理には、会話とは別の正本が必要だということ。
賢いAIを増やすだけではなく、AIが古い前提を持ち込まず、現在の仕事へ戻れる運用面を作っておく。
この記事で触れたAIエージェントの考え方を、もう少し手元の仕事へ落とし込みたい人には、タスクの分け方から読める入門書も次の一歩になる。
ここで紹介するのは自分の実使用品ではなく、記事内容とつながる参考書として選んだものです。
ポチップ