Codexのthread toolで、AIチームの役割スレッドをつなぐ

AIチームで開発やブログ運用を進めていると、役割を分けるだけでは足りないことに気づく。
Director。
Engineer。
Tester。
Designer。
Document Owner。
Assistant Director。

それぞれの役割を分けると、会話はかなり整理される。
でも今度は、役割同士の受け渡しが増える。

誰に何を渡したのか。
どの状態から作業しているのか。
何をやって、何をやらないのか。
どこまで終わったらDirectorに戻すのか。

ここが曖昧になると、AIチームは便利になるどころか、ただ会話が散らかっていく。

そこで最近、Codex appのthread管理やtool_searchを使って、役割スレッド同士の受け渡しをどう整えるかを試している。
この記事は、その実践記録。

結論から言うと、AIチームで大事なのは、AIを増やすことではない。

受け渡しを壊さないこと。

ここまでの経緯

以前、
AIチームと作る、ぼっち事業のOS
という記事を書いた。
そこでは、4つのブログ、公式サイト、事業集計、日次レポート、AIとの作業体制をつなげて、自分の事業を動かす仕組みを作っている話をした。

そのあと、
Claude × Codexで、ぼっち開発をAIチーム化している
という記事では、ClaudeやCodexに役割を持たせながら開発を進めている話を書いた。

さらに、
AIチームでブログをリライトする
では、昔書いた記事をAIチームと一緒に読み直し、タイトル、description、導入、画像alt、内部リンク、公開後チェックまで見直していることを書いた。
AIに文章を丸投げするのではなく、編集部のように役割を分けて、古い記事を今のメディア資産に戻していく作業。

Codex × Google APIで日々の事業集計を報告してもらう話
では、数字を見る場所を作り、AIに日々のレポートを読ませる流れを書いた。
Search Console、GA4、AdSense、ASP、AI visibility。
そういう数字を毎日見て、次に何を直すか、何を書くかを考える。

X APIに課金せず、CodexでX投稿をAIチーム運用にした話
では、投稿候補を作り、人間が確認してから出す運用を書いた。
ここでも大事なのは、完全自動ではなく、候補、確認、投稿、記録の流れを作ること。

つまり、ここまでやってきたのは「AIに作業を丸投げする」ことではない。
事業OSを作る。
AIチームに役割を持たせる。
ブログを編集部のように見直す。
数字を見る。
運用作業を候補制にする。

その流れの次に出てきたのが、今回のthread toolの話。

役割を分けたAIチームを、どうつなぐか。

これまでの記事では、AIチームの役割や、実際の運用例を書いてきた。
今回の記事では、その一段下にある「受け渡し」の話をする。

役割を分けると、次は受け渡しが問題になる

役割を分けること自体は、かなり効く。
同じCodexでも、Directorとして見るときと、Engineerとして見るときでは、頼むべきことが違う。
Testerとして見るなら、期待値と実値を照合してほしい。
Document Ownerとして見るなら、人間向けの文書に残すべきことを判断してほしい。

「何でもやって」ではなく、「この役割として、この範囲を、この完了条件で」と渡す。

これだけで、AIとの仕事の進み方は変わる。

ただ、実際にしばらく回していると、次の問題が出てきた。

役割を分けるほど、handoffが増える。

DirectorがEngineerへ渡す。
Engineerが実装結果を返す。
Testerが確認する。
Document Ownerがdocs更新の要否を見る。
最後にDirectorがclose判断をする。

この受け渡しを、人間が毎回コピペしていると少しずつ崩れる。
古い前提を渡す。
やらないことを書き忘れる。
完了条件が抜ける。
Testerの報告がDirectorへ戻らない。
どのthreadに何を頼んだのか分からなくなる。

AIチームは、役割を分けた瞬間に完成するものではない。
役割同士をどうつなぐかまで設計して、ようやく運用になる。

Codexのthreadは、ただの会話履歴ではなく作業単位

Codex manualでは、threadは1つのsessionとして説明されている。
最初のprompt、modelの出力、tool call、その後のfollow-up promptを含む作業単位。

僕はこのthreadを、ただの会話履歴ではなく、作業の単位として見ている。

Director thread。
Engineer thread。
Tester thread。
Document Owner thread。

そうやって分けると、作業ログの意味が変わる。
Director threadには方針、scope、やること、やらないこと、close判断を残す。
Engineer threadには実装、build、verify、差分整理を残す。
Tester threadには期待値、確認手順、実際の挙動、NG時の再現条件を残す。
Document Owner threadには、あとから人間が読むための決定や文書更新判断を残す。

もちろん、全部を必ず別threadにすればよいわけではない。
小さい修正なら、ひとつのthreadで最後まで進めたほうが速い。
役割を分けすぎると、逆に重くなることもある。

でも、少し大きい作業では、会話を分けたほうが見通しがよくなる場面がある。
特に、実装、確認、ドキュメント、公開判断が混ざるとき。

このときに、threadを作業単位として扱う意味が出てくる。

Codex appは、複数thread前提の作業場所になっている

Codex appは、複数のCodex threadを並行して扱うdesktop experienceとして説明されている。
さらにmanual上では、利用できる場合、Codexに関連threadを探す、既存threadを続ける、pin/archiveする、といったthread管理を頼めることも書かれている。

ここが面白いところ。

AIチーム運用では、threadが増える。
Directorのthread。
実装用のthread。
確認用のthread。
記事執筆用のthread。
docs整理用のthread。

人間がそれを全部覚えて、毎回探して、文面を貼って、結果を戻すのは地味に重い。
地味だけど、ここが崩れると作業全体が崩れる。

Codex app側にthread管理の口があるなら、AIチームの受け渡しに使えるのではないか。
そう考えて、tool_searchで確認してみた。

公式manualで見えるthreadまわりの現在地

ここで、いったん公式manualで確認できる範囲を整理しておく。

まず、Codexにはthreadという単位がある。
これは、1回の質問だけではなく、prompt、出力、tool call、follow-up promptを含むsession。
つまり、threadはただのチャット履歴ではなく、作業が進んでいく場所として扱える。

Codex app側では、threadを扱うための操作も用意されている。
New thread。
Search threads。
Find in thread。
Previous thread。
Next thread。
/status でthread IDを確認する。

さらに、deep linkとして codex://threads/new や、既存threadを開く codex://threads/<session UUID> のような形もある。
新規threadには、query parameterで初期promptやworkspace pathを渡せる。

これだけでも、役割スレッド運用とは相性がいい。
Engineer向けの初期promptを用意しておく。
Tester向けの確認promptを用意しておく。
Document Owner向けのdocs更新判断promptを用意しておく。

そうすると、AIチームのhandoffを毎回ゼロから書くのではなく、ある程度定型化できる。

もう少し開発者向けの口もある。
Codex app-serverでは、Thread、Turn、Itemがcore primitiveとして扱われている。
threadをstartする。
resumeする。
forkする。
turnをstartする。
進行中のturnをsteerする。

Codex SDKにも、threadを開始したり、同じthreadで続けたり、thread IDを指定して再開したりする口がある。
ここまで見ると、Codexは単発のチャットではなく、threadを軸に作業を積み上げる方向へかなり寄っているように見える。

ただし、この記事で扱っている create_thread や send_message_to_thread という具体tool名が、公式manual上にそのまま公開API名として載っているわけではない。
ここは分けて書く必要がある。

公式manualで確認できるのは、threadという作業単位、Codex appでのthread検索や継続、pin/archiveを頼める場合があること、app-serverやSDKでもthreadが中心概念になっていること。
一方で、今回の codex_app namespaceのtool名は、この環境でtool_searchから実際に露出したtool surface。

僕の記事では、この2つを混ぜないようにする。
公式に確認できること。
この環境で観測できたこと。
まだ確認していないこと。

この3つを分けて書く。

tool_searchで、その環境のtool surfaceを探す

tool_searchは、今の環境で使えるtoolを探して露出させるための仕組み。
すべてのtoolが最初から見えているわけではなく、必要に応じて検索し、使えるものを確認する。

今回、thread management系のtoolが使えるかを確認するため、次のような名前を探した。

• create_thread
• list_threads
• read_thread
• send_message_to_thread
• set_thread_title
• set_thread_pinned
• set_thread_archived

最初の調査では、期待したtoolは出なかった。
GitHubのPR review thread系toolや、subagent系のtoolは見えた。
でも、Codex appのthreadを直接扱うようなtoolは、その時点では見えなかった。

そこで終わりにしてもよかったのだけど、あらためて同じ系統のqueryで探したところ、別のターンでは codex_app namespaceのthread management系toolが露出した。

このあたりが、今回の記事でいちばん書きたかったところ。

toolは、常に同じように見えるとは限らない。
環境、plugin、connector、Codex app側の状態、ロールアウト、検索語によって、見えるsurfaceが変わる可能性がある。

だから、「Codexには誰でもこのtoolがある」とは書けない。
でも、「この環境では、tool_searchでCodex appのthread管理toolが露出した」とは書ける。

これは一次観測として、かなり価値があると思っている。

この環境で確認できたthread management系tool

今回の環境では、tool_search後に次のtoolが確認できた。

tool	できること	今回の扱い
create_thread	新しいCodex threadを作る	検証専用threadを作って確認
list_threads	recent threadsを一覧またはqueryで探す	検証threadをqueryで検索
read_thread	指定threadのstatusやturn summaryを読む	検証threadだけをID指定で確認
send_message_to_thread	既存threadへfollow-up promptを送る	検証threadへ短いpromptを送信
set_thread_title	thread titleを変更する	検証threadのtitle変更を確認
set_thread_pinned	pin / unpinする	pinとunpinを確認
set_thread_archived	archive / unarchiveする	archiveは確認。unarchiveはこの環境で制約あり

今回は、検証専用threadを1つ作って、そこだけを対象に試した。
既存の作業threadは読まない。
既存の作業threadへ送らない。
記事のために必要な挙動だけを、安全な範囲で確認する。

create_thread では、同じblog workspaceのlocal環境に検証用threadを作れた。
初回promptでは「実作業はしない」「ファイル編集もコマンド実行もしない」「受信確認だけ返す」と明示した。

その直後に read_thread を使うと、作成直後のturnは inProgress として見えた。
少し待って再度読むと completed になり、agent messageとして「検証用threadとして待機します。」という返答も読めた。

ここで面白かったのは、promptがただの本文としてではなく、delegationの形で記録されていたこと。
source threadの情報と、送ったinputがまとまって見える。
もちろん、公開記事に実IDは出さない。
でも、thread間の受け渡しが構造化されて残ることは確認できた。

list_threads では、検証用のqueryで作成したthreadを探せた。
set_thread_title でtitleを変えると、そのtitleでも確認できた。
set_thread_pinned はpin、unpinともに成功した。

send_message_to_thread も試した。
検証threadへ「受信確認だけ返す」という短いfollow-up promptを送り、read_thread で見ると新しいturnが追加されていた。
返答も「受信確認: send_message_to_thread」として読めた。

つまり、少なくともこの環境では、別threadを作り、そこへfollow-upを送り、あとからturn summaryとして読むところまで動いた。
これは、AIチームのhandoff用途としてかなり大きい。

一方で、set_thread_archived は注意が必要だった。
archive自体は成功した。
archive後は list_threads の検索結果から消えた。
ただし、IDを指定した read_thread では、archived後も内容を読めた。

問題はunarchive。
今回の環境では、archiveした検証threadを set_thread_archived で戻そうとすると、unloaded threadにはhostIdが必要という趣旨のエラーになった。
tool schema上は threadId と archived だけを受け取るように見えるけれど、実際の運用では内部状態によって戻せないケースがあるらしい。

ここはかなり実務的な発見。

使えることと、戻せることは違う。
特にarchiveは、記事の検証で気軽に触るtoolではない。
実作業で使うなら、対象threadと戻し方を確認してから使ったほうがいい。

thread managementが使えると、役割スレッドを直接つなげられる

今回 send_message_to_thread を実際に使ってみて、AIチームのhandoffは少し変わると感じた。

たとえばDirector threadで方針を決める。
Engineer向けのhandoffを作る。
対象のEngineer threadを確認する。
そこへfollow-up promptとして渡す。

Engineerが作業したら、結果をDirectorへ戻す。
必要ならTester threadへ確認依頼を送る。
Testerの報告をDirectorが読み、closeするか、Engineerへ戻すかを判断する。

これを全部人間がコピペするより、thread管理toolで補助できたほうが楽。
もちろん、自動で全部流せばよいという話ではない。

送信先を間違えたら危ない。
機密情報を入れたまま送ったら危ない。
古いhandoffを送ったら、古い前提で作業が進む。

だから、thread toolを使うなら、送信前の確認が必要になる。
thread title。
thread ID。
送るhandoffの内容。
機密情報の有無。
やること。
やらないこと。
完了条件。

AIチームの受け渡しを楽にするtoolほど、雑に使うと事故る。

subagentとは似ているが、少し違う

ここで、subagentとの違いも整理しておきたいところ。

Codexにはsubagent workflowがある。
明示的に頼むと、specialized agentsを並行して動かし、それぞれの結果をまとめることができる。
read-heavyな探索、test、triage、summaryにはかなり向いている。

これは公式に説明されている仕組み。
Codex appやCLIでもsubagent activityが表示される。
subagentは親のsandbox policyも継承する。

ただ、僕がここで書きたい役割スレッド運用とは、少しだけ違う。

subagentは、ある作業のためにspawnする並行作業者に近い。
一方で、役割スレッドは、Director、Engineer、Tester、Document Ownerのような役割を継続的に使い分ける運用に近い。

どちらが上という話ではない。
用途が違う。

探索やレビューを並列化したいなら、subagentが向いている。
継続的な作業ログや判断の流れを役割ごとに残したいなら、threadを分けるほうが向いている。

僕の今の使い方では、両方を組み合わせている。
mainのDirector threadで判断し、必要に応じてsubagentに探索や確認を渡す。
一方で、長く残したい役割の流れは、threadとして分けておく。

そういう使い分け。

handoffには、何を渡して、何を渡さないかを書く

役割スレッドをつなぐうえで、結局いちばん大事なのはhandoff。

toolが使えても、handoffの中身が曖昧なら崩れる。
むしろ、toolで速く送れるぶん、曖昧な指示も速く広がる。

僕がhandoffに入れるようにしているのは、だいたい次のような項目。

• 目的
• 対象範囲
• やること
• やらないこと
• 触ってよいファイルや画面
• 触らないファイルや画面
• 現在の状態
• 完了条件
• verify方法
• 報告形式
• Directorへ戻す条件

開発系なら、実際にはrepo、branch、worktree、HEAD SHAなども必要になることがある。
ただし、公開記事には実名や実IDは出さない。
ここでは、そういう情報をhandoffに含めることがある、という話に留める。

Engineerへ渡すhandoffと、Testerへ渡すhandoffは違う。
Engineerには実装範囲と完了条件を渡す。
Testerには期待値、確認手順、見るべきURLや画面、NG時の報告形式を渡す。
Document Ownerには、何をdocsへ残すべきか、何は残さなくてよいかを渡す。

役割ごとに、渡す情報が違う。
そこを揃えると、AIチームの出力が扱いやすくなる。

送信先を間違えない。機密情報を送らない

thread管理toolを使うなら、安全面はかなり大事。

特に、send_message_to_thread のような既存threadへ送るtoolが使える場合。
これは便利だけど、送信先を間違えると困る。
本来Engineerへ渡す内容を、別の作業threadへ送ってしまうかもしれない。
内部情報を含んだhandoffを、公開用の記事threadへ送ってしまうかもしれない。

なので、僕なら実際に送る前に必ず確認する。

このthreadで合っているか。
titleは合っているか。
役割は合っているか。
送る内容に、thread ID、実際のrepo名、worktree path、branch名、HEAD SHA、顧客名、管理画面URL、token、credentialが入っていないか。

AIチーム運用では、速さよりも受け渡しの正確さが効く。

速く送ることより、正しく渡すこと。

ここを外すと、AIチームは加速装置ではなく、混乱を広げる装置になる。

AIチームは、自動化よりも運用設計が大事

AIチームという言葉は、少し派手に聞こえる。
でも、実際にやっていることはかなり地味。

役割を決める。
handoffを書く。
threadを探す。
送信先を確認する。
終わったら戻す。
docsに残すか判断する。
公開後に確認する。

どれも地味。
でも、この地味な部分がないと、AIとの作業はすぐ流れていく。

僕はいま、AIに全部を自動化してもらいたいわけではない。
むしろ、自分の判断を残しながら、ひとりでは回しきれない作業をチームの形にしている感覚。

ブログをリライトする。
事業集計を見る。
X投稿候補を作る。
開発を進める。
公開HTMLまで確認する。

こういう作業を、AIチームと一緒に回す。
そのために、threadとhandoffを整えている。

今回のthread toolは、その受け渡しを支えるための部品。
主役はtoolではなく、運用設計。

まだ途中。でも、ぼっち開発の形が少し変わった

正直、この領域はまだ情報が少ない。
公式manualに書かれていること。
今の環境で実際に見えたtool。
使ってよい場面。
まだ触らないほうがよい場面。

それぞれを切り分けながら進める必要がある。

でも、情報が少ないからこそ、今の段階で記録しておく意味があるとも思っている。

Codex appでthreadを分ける。
tool_searchでその環境のtool surfaceを確認する。
使える場合はthread管理をhandoffに組み込む。
使えない場合も、deep linkや手動handoffで受け渡しを整える。

このあたりを少しずつ試していると、ぼっち開発の感覚が変わってくる。

ひとりで考えて、ひとりで作って、ひとりで確認している。
それは今も同じ。

でも、作業の中にはDirectorがいて、Engineerがいて、Testerがいて、Document Ownerがいる。
それぞれの役割に、必要な文脈を渡して、戻ってきた結果を見て、次の判断をする。

AIチームで大事なのは、AIを増やすことではない。

受け渡しを壊さないこと。

Codexのthread toolは、そのための小さな、でもかなり実務的な入口になりそう。