AIチーム運用で、最近かなり大きい変化があった。
人間が、AI作業者たちの伝言係をしなくてよくなってきた。
これは地味だけど、かなり大きい。
これまで、AIに役割を持たせて作業することはできていた。
Directorとして方針を見る。
Engineerとして実装する。
Testerとして確認する。
DesignerとしてUI案を見る。
Document Ownerとしてドキュメントに残すか判断する。
ただ、そのあいだの受け渡しは、人間が抱えていた。
Engineerの報告を読み、Testerに貼り直す。
Testerの指摘を読み、Engineerに貼り直す。
最後にDirectorへ戻す。
作業そのものはAIが進めているのに、伝言だけ人間がやっている。
ここが、じわじわ重かった。
前に、Codexのthread toolで、AIチームの役割スレッドをつなぐ という記事を書いた。
そこでは、Codex appのthread toolを使うと、Director、Engineer、Testerのような役割スレッドを直接つなげられる、という話をした。
今回はその続き。
役割スレッドをつなぐだけではなく、handoff、報告、差し戻しまで、AI側でかなり回せるようになってきた。
もちろん、全部を自動で流せばよいという話ではない。
今のところ、僕の環境で観測している実践記録です。
すべてのCodex環境で、同じtool surfaceが常に見えるとは限らない。
それでも、見えてきた方向はかなりはっきりしている。
AIを1人の万能アシスタントとして使う段階から、役割を持った小さなチームとして運用する段階に入ってきた。
AI開発で、人間が伝言係になっていた
1つの長いチャットに、仕様相談、実装、テスト、差し戻し、判断を全部入れることもできる。
小さい作業なら、それで十分なこともある。
でも、少し大きくなると混ざる。
方針の話をしていたはずなのに、途中から実装の細かい話になる。
実装の報告を読んでいたら、テスト観点が抜けている。
テストでNGが出たけれど、どの前提でEngineerへ戻せばいいか分からない。
そこで役割スレッドを分ける。
Directorは方針を見る。
Engineerは実装する。
Testerは期待値と実際の挙動を照合する。
ここまではかなり効く。
ただ、次の問題が出る。
誰が、誰へ、何を渡すのか。
従来は、ここを人間がやっていた。
DirectorのhandoffをEngineerに貼る。
Engineerの完了報告をTesterに貼る。
TesterのNGをEngineerに貼る。
TesterのOKをDirectorに貼る。
地味。
でも、ずっと地味に重い。
しかも、人間が伝言係になると、そこで情報が落ちる。
やらないことを書き忘れる。
確認条件を抜かす。
古い前提を貼る。
送る相手を間違える。
AIチームのボトルネックが、AIではなく人間のコピペになる。
これは避けたい。
thread toolで、スレッド間handoffまで回せるようになった
Codexのthread toolが使える環境では、役割スレッド間に直接メッセージを送れる。
少なくとも僕の環境では、tool_searchでthread management系のtoolを確認し、send_message_to_threadを使った受け渡しまで動かせた。
ここで変わるのは、単に「便利な送信機能がある」ということではない。
Engineerが実装を終えたら、自分でTesterへテスト依頼を送れる。
TesterがNGを見つけたら、自分でEngineerへ差し戻せる。
TesterがOKなら、自分でDirectorへ報告できる。
Directorは、最終判断とhideへの説明に集中できる。
人間は転送作業から外れる。
もちろん、GOを出すのは人間。
最終判断も人間。
公開してよいか、どこで止めるかも人間。
でも、AI作業者同士の伝言まで人間が毎回抱えなくてよくなる。
ここが大きい。
作業の流れが、少しチームっぽくなる。
役割スレッドを、継続するチームとして扱う
今の運用では、Codexを1つの長いチャットとして見ていない。
役割ごとの継続スレッドとして見ている。
Director。
Engineer。
Tester。
Designer。
Document Owner。
Assistant Director。
それぞれのスレッドには、少しずつ違う文脈が残る。
Directorには、目的、優先順位、やること、やらないこと、判断の履歴が残る。
Engineerには、実装方針、差分、検証、commitやpushの状態が残る。
Testerには、期待値、再現手順、NG条件、OK判断が残る。
Designerには、UIの違和感、操作感、代替案が残る。
Document Ownerには、何を文書に残すか、何を残さないかの判断が残る。
毎回ゼロから説明し直さなくてよい。
これが、単発のAI呼び出しと違うところ。
もちろん、すべてを分ければよいわけではない。
小さい修正なら、1つのスレッドで終わらせた方が速い。
役割を分けすぎると、逆に運用が重くなる。
ただ、仕様相談、UI判断、実装、E2E確認、差し戻しが混ざる作業では、分ける意味が出る。
実際に、作業時間入力UIの改善で回してみた
実際に使った題材は、開発中Webアプリの作業時間入力UIだった。
ここでは具体的なrepo名やURL、commit SHA、thread IDは出さない。
公開できる範囲に抽象化して書く。
最初は、作業にかかった拘束時間を必須入力にする案があった。
時間と分を手動で選ぶ。
入力フォームの中で、きっちり値を入れてもらう。
仕様としては分かる。
でも、スマホ前提で見ると重い。
hideからも、これは違うというフィードバックが入った。
ステッパーっぽい入力ではない。
この操作感ではダメ。
そこでDesignerスレッドにUI案を見てもらった。
単に「入力欄を作る」ではなく、モバイルで自然に触れるか。
未入力のときにどう見えるか。
入力したい人だけが入力できるか。
キャンセルしたときに値が壊れないか。
最終的には、拘束時間は任意入力にした。
通常画面では「拘束時間 / 未入力 / 入力する」のように見せる。
入力するときだけ、ボトムシートを開く。
シート内ではdraft値を操作する。
登録するを押したときだけ、フォーム値へ反映する。
キャンセルや×では、元の値を維持する。
未入力に戻す導線も用意する。
この方針をDirectorが整理し、Engineerへhandoffした。
Engineerが実装する。
保存後の詳細画面や結果画面にも表示を反映する。
Testerが確認する。
ここまでは、よくある開発フローに見える。
でも、実際には役割スレッド間で回している。
Designer案。
Director判断。
Engineer実装。
Tester検証。
NGならEngineerへ差し戻し。
OKならDirectorへ報告。
人間は、全部の伝言を貼り直していない。
ここが変化だった。
不足観点を、あとから潰せるようになった
このUI改善では、拘束時間入力だけを見れば終わりではなかった。
Testerが見ると、周辺のE2E観点も出てくる。
日単位削除。
前日 / 翌日ナビ。
24時間境界。
未来日セル。
エラー表示。
保存後の詳細画面。
結果画面への反映。
ひとつひとつは細かい。
でも、公開品質としては薄くできないところ。
AIに実装だけ頼むと、ここは抜けやすい。
「仕様どおり作りました」で終わってしまう。
Testerスレッドがあると、少し違う。
実装結果を読む。
期待値を確認する。
足りない観点を出す。
必要ならEngineerへ戻す。
そしてEngineerが修正し、再検証する。
この流れを、人間が毎回全文コピペしなくてよくなる。
これはかなり助かる。
もちろん、人間が見なくてよいわけではない。
むしろ最後の判断は人間が見る。
ただ、途中の作業リレーをAI側に寄せられる。
そのぶん、人間は「何をOKにするか」「どこをまだ不安と見るか」に集中できる。
サブエージェントではなく、継続スレッドとして使う
ここは、subagentとの違いも整理しておきたい。
サブエージェントは便利。
一時的な調査、並列確認、別視点のレビューには向いている。
必要なときに呼び出し、結果をまとめて戻す。
一方で、今回の運用は少し違う。
DirectorスレッドはDirectorとして残る。
EngineerスレッドはEngineerとして残る。
TesterスレッドはTesterとして残る。
それぞれが継続した文脈を持つ。
前回の判断。
前回のNG。
どこまで確認したか。
どの範囲は触らないか。
どの報告先へ戻すか。
こういう情報が、役割ごとの作業場所に残る。
AIチーム運用として意味があるのは、ここだと思っている。
単発で賢いAIを呼ぶのではなく、役割のある場所を作る。
1人のAIに全部を頑張らせるより、複数の役割に分けた方が作業の流れが見えやすい。
ただし、運用ルールはかなり大事
thread toolが使えると便利。
でも、便利なほど危ない。
送信先を間違えたら、違うスレッドにhandoffが届く。
古い前提を送れば、古い前提で実装が進む。
機密情報を入れたまま送れば、そのまま残る。
だから、運用ルールは必要。
まず、tool_searchで、その環境でthread toolが使えるか確認する。
使える場合だけ、send_message_to_threadを使う。
使えない場合は、送れなかった理由と、コピペ用handoffを返す。
handoffには、対象範囲を書く。
やることを書く。
やらないことを書く。
確認条件を書く。
報告先を書く。
必要なら、現在の作業基準も書く。
一方で、公開記事やhandoffに出してはいけないものもある。
thread ID。
社内repo名。
commit SHA。
ログイン情報。
管理画面URL。
token、cookie、secret。
API body。
取引先や会社が特定できる情報。
ここはかなり強めに線を引く。
AIチームを回すほど、情報は流れやすくなる。
だからこそ、流してよい情報と、流してはいけない情報を分ける必要がある。
自動化より先に、運用設計。
ここを飛ばすと、便利な仕組みではなく、危ない仕組みになる。
まとめ：AIは1人で頑張らせるより、役割で分けた方が強い
今回、いちばん大きかったのは、AIがさらに賢くなったことではない。
人間が伝言係から少し外れたことだった。
Directorが整理する。
Engineerが実装する。
Testerが確認する。
NGならEngineerへ戻す。
OKならDirectorへ戻す。
この作業リレーを、役割スレッド間で回せるようになる。
人間は、全部の伝言を貼り直さなくていい。
その代わり、GOを出す。
止める。
判断する。
品質を見る。
AIをよく働く1人として使うのも便利です。
でも、少し大きい作業では、役割を持った複数人として設計した方が強い。
今のところ、僕にとってCodexのthread toolは、その方向に進むためのかなり重要な部品になっている。
まだ途中。
環境差もある。
いつでも誰でも同じように使える、とまでは言わない。
でも、少なくともこの環境では、AI開発チームの運用は少し変わった。
人間が伝言係をやめる。
AI同士が作業をリレーする。
人間は、最後の判断に集中する。
AIチーム運用は、そこまで来始めている。
あわせて読みたい本
AIエージェントや、生成AI時代のプロダクトづくりを考えるときに、手元に置いておきたい本も置いておく。
この記事で書いた「AIを役割で分けて運用する」感覚を、もう少し広い視点で見直すときに相性がいい。
ポチップ