dotとCodexで仕事を回す。依頼から結果回収までを確かめた実例

AIに仕事を任せたあと、実行した担当から完了の報告が返ってくる。
でも、その結果を次の判断をする相手が読んだかどうかは、別に確かめる必要がありました。

2026年10月19日、自作ツールの紹介提案をCodexの担当に任せ、その結果をChatGPTのdotへ戻すところまで確認しました。
途中には僕の承認があり、結果を読んでもらうための追加通知も1回あります。
手放したまま全部が自動でつながった、という話ではありません。

今回は、接続できたかではなく、何を任せ、何が実行され、誰がどの結果を読んだかを残します。
仕事の終わりを、完了というひと言にまとめないための実務記録です。

「終わった」の先に、結果の受け取りがある

dotを使い続ける中で、僕は相談の答えだけでなく、その先の仕事も扱うようになりました。
使い始めた経緯は、ChatGPTのdotを使い続けている記録へ分けています。
この記事では、その後の具体的な一件に絞ります。

実行する担当、結果を集める調整役、dotへ伝える中継役。
自分の環境では、これらを分けて仕事を進めています。
中継役は、担当が残した結果を読み、dotが判断できる形へまとめて返す役目です。

役が増えると、途中まで進んだ状態も増えます。
担当の作業は終わったけれど、報告は保存先にあるだけ。
調整役は読んだけれど、dotが読んだことはまだ確認できない。

どちらも作業が消えたわけではありません。
ただ、その時点で「全部終わった」とすると、どこから続ければよいかが分からなくなる。
実行と、結果の返却を分けて見る理由はここにあります。

外部へ送る内容は、僕が先に承認した

今回紹介したのは、技術記事の公開前に根拠や確認状態を整理する自作ツール、Evidence Gateです。
記録された情報を扱う道具で、文章の真偽を自動で保証するものではありません。

開発者向けニュースレターのConsoleと、Pythonのニュースを扱うポッドキャストPython Bytesへ、紹介候補として提案を送りました。
誰にでも同じ文面を一斉送信したのではなく、宛先と最終文面を分け、それぞれ僕が承認しています。

Consoleは9時12分に、Python Bytesは9時35分に送信を承認しました。
実行したのは既存のCodex担当です。
dotが外部連絡を発案し、相手選びから送信まで自律的に指揮した事例ではありません。

送ってよいのは、承認した内容の1通だけ。
返事がない時の催促、別の宛先への送信、追加の条件提示まで任せたわけではない。
調べること、下書きを作ること、実際に送ることは、別々に範囲を決めました。

同じ時期には製品ページの改善も行っていますが、そちらは別の依頼経路です。
日付と製品が同じだからといって、その公開まで今回のdotへの結果返却に合算しません。

送信済みと、自動受付と、掲載は違った

担当は、送信操作が成功したという報告だけで終えませんでした。
送信された同じメールのSENTを読み直し、宛先、件名、承認本文との一致を確認しています。
Consoleは9時15分、Python Bytesは9時36分に、それぞれ1回の送信を確認しました。

Consoleからは自動受付がありました。
担当は元の送信に結び付く応答であることと、自動返信を示す情報を確認しています。
ただし、これで編集者が個別に審査した、紹介が決まった、とは言えません。

Python Bytesで確認できたのは、承認した本文の送信済みまでです。
相手の開封、返信、採用、掲載、実際の利用は、今回の記録からは確認していません。

確認したもの	そこからは言えないこと
承認本文と一致する送信済みメール	相手が開封した
Consoleの一般的な自動受付	人が個別審査し、採用した
担当が保存した結果報告	dotがその報告を読んだ
dotによる中継回答の受領	dotが元メールや原ファイルを直接調べた

同じ完了報告でも、確認した対象が違えば意味が変わります。
今回の僕に必要だったのは、良さそうな反応としてまとめることではなく、確認できたところで止めた報告でした。

保存しただけでは、dotへ返ったことにならない

実行担当は結果を保存し、調整役は担当の回答と保存資料を回収しました。
そこまでは進んでいる。
でも、それだけでdotが受け取ったとは扱いませんでした。

10時2分、僕は今回の結果回収に限って、既存のdotの会話へ通知を1回送ることを許可しました。
その許可の範囲で、回収を促す通知が1回送られています。
メール送信をやり直したのではなく、保存済みの結果を読むための連絡です。

その後、中継役が担当の保存資料と結果報告を照合し、詳細な回答を返しました。
10時5分、dotはその中継回答を全文読んだと明示しています。
受領の返答も後から照合し、今回の結果が戻った範囲を確認しました。

ここでdotが読んだのは、中継がまとめた回答です。
元メールや原ファイルをdotが直接開いたことを示す記録ではありません。
Consoleの自動受付とPython Bytesの送信確認について、担当が確かめた結果を受け取った、という範囲です。

追加通知が必要だったことも、この実例から省けません。
僕が何もせずに結果が必ず戻る仕組みを実証したわけではないからです。
途中で結果が見えない時も、元の仕事を繰り返すのではなく、まず保存済みの成果がどこまで届いたかを確認しました。

公式の機能と、僕の分担は分けて読む

OpenAIのTasks and memoryのAssigned workでは、接続したPC上の既存Codexタスクを継続する使い方が案内されています。
一方で、PCにつないだだけで既存のすべての会話を読めるわけではありません。
また、dotが作成した仕事の結果確認や追指示には、その仕事を作成した元のPCやクラウド環境を使うとされています。

同じ公式文書は、実行が完了しても、求めた結果の達成や配送まで確認できたとは限らないと注意しています。
今回分けて見たかったのも、まさにその部分でした。

Control your dotには、Activityから進捗、ファイル、結果、入力要求を確認する方法が載っています。
下書きを頼むことは送信の許可ではなく、カスタムルールも接続権限や必須の確認を取り除くものではありません。
ここは公式文書を読んで整理した部分で、今回その全画面を操作して試したわけではありません。

僕の調整役や中継役の分担まで、標準で付いてくる機能だとは考えていません。
同じ依頼文なら、どの環境でも同じ担当へ届くという保証もない。
まずは自分の環境で、対象を読めるか、誰が実行し、何を返せるかを確認する必要があります。

依頼する時に、返してほしいものも書く

以前、AIのタスク管理を会話ログから正本へ移した話を書きました。
今回も、会話の記憶だけを頼りに完了を判断するのではなく、残っている結果へ戻ることが大事でした。

読者が小さく試すなら、まずは変更しない確認の仕事でよいと思います。
依頼文には、目的だけでなく、対象、担当、対象外、返却内容を入れる。
次はそのための例で、当時の会話の引用ではありません。

目的：指定した作業の現在状態を確認する。
対象：今回指定した1件と、その保存済み結果だけ。
担当：その作業を受け持つ既存の担当。
範囲：読み取りと照合だけ。
対象外：変更・公開・外部送信。
返却：確認者、確認対象、結果、不明点、次の判断をまとめる。
停止：読めない・対象が違う場合は、推測で埋めず停止箇所を返す。

結果を読む時も、完了したかだけを聞かないようにします。
何を見てそう判断したのか、その確認を誰がしたのか。
保存された報告を読んだのか、元の対象を直接確認したのかまで見る。

報告は、次に判断できる短さへ戻す

細かな記録が必要でも、受け取るたびに全部を読み直す形では続けにくい。
僕は、結果と未確認を短く並べ、必要な時に根拠へ戻れる形にしたい。
今回の確認例なら、次のくらいです。

実行：承認した紹介提案を、それぞれ1回送信した。
確認者：実行担当。
根拠：同じ送信メールのSENTと、承認本文との一致。
返却：dotが、中継からの詳細回答を読んだことを確認した。
未確認：先方の掲載、第三者の実利用。
次の判断：追加送信はせず、許可した範囲の確認だけを続ける。

これは読者向けに再構成した報告例で、私信の転載ではありません。
確認者や対象が抜けると、実行担当の確認と、dotの理解が一緒になってしまう。
短くする時にも、そこは削らずに残したい部分です。

依頼文を工夫する前に、何に答えが出れば仕事が進むかを整理したい時は、安宅和人さんの『イシューからはじめよ［改訂版］』も次に読む候補になります。
問いの見極め方と、アウトプットや伝える内容の組み立てを扱う出版社の目次から選びました。
僕の読了記録でも、dotの操作仕様を説明する出典でもありません。

まとめ。仕事の終わりを、受け取り方まで決める

今回確認できたのは、人が承認した紹介提案を担当が実行し、その確認済み結果が中継回答としてdotへ戻ったことです。
自動受付を掲載に変えたり、回答の受領を元メールの直接確認に変えたりはしません。

任せる前に、何をしてよいかと、何を返してほしいかを書く。
終わったあとに、結果、根拠、確認者、不明点を読む。
これからも、その小さな往復を確かめながら仕事を任せていきたいと思います。

参考・出典

• Tasks and memory — Assigned work／OpenAI
• Control your dot／OpenAI

公式仕様の確認日：2026年10月21日。
実務例は2026年10月19日の保存記録に基づき、dotの受領確認は同日10時5分時点の範囲です。
掲載、第三者利用、時間・利用量の削減効果を測定した記事ではありません。