ChatGPT Dotsに朝から午後まで開発を任せてみた――仕事はつながった、でもまた止まった
朝から15:58までDotsに任せた2案件を観察。Workへの次の指示、サブエージェントの結果統合、人へ戻す技術判断まで進みました。一方で午後には両案件が再び停止。仕事をつなぐ力と、つなぎ続ける難しさの両方が見えました。
前回の記事では、最後にこんなことを書きました。
今度は通知が来ても、できるだけ開かずに置いてみます。
確認したかったのは、Workが一区切りするたびに私が「続けて」と言わなくても、Dotが次の仕事を選び、人が見ていない間も開発を続けられるのかということでした。
ところが、その夜は少し違う理由で実験が止まりました。PCがスリープに入っていました。
今回の2案件は、当社のPCにある開発環境を使っています。PCがスリープすれば、そのローカル環境を使った作業も止まります。つまり、前回の夜だけでは「Dotが人の操作なしで朝まで仕事をつなげられるのか」は確認できませんでした。
そこで翌朝、PCを起こして続きを見てみることにしました。ここからが、2026年10月2日の朝7時半過ぎから15:58まで、途中の更新・再起動も挟みながら観察した第3回の記録です。
朝は「次の仕事をDotがつなげるか」を見ていました。午後には、Workがサブエージェントへ仕事を分け、その結果を統合し、人の回答も取り込んで次へ進むところまで見えました。ところが、そのあと両案件とも再び止まります。観察を続けるうちに、Dotに何ができて、どこで人がまだ見ている必要があるのか、問いも変わってきました。
朝、PCを起こし、保存地点から続きを始めた
PCを起こしたあと、前日から動かしていた2案件の状態を確認しました。一つは樋門設計に関するAIエージェントの開発、もう一つはCreer AI技術室です。
前回までに、Dotには「人の技術判断や最終承認が必要なところでは確認する。それ以外は、決まった方針の範囲で調査、変更、テスト、記録更新を進めてよい」と伝えてあります。朝の時点でも、その方針は引き継がれていました。
ただ、この日は途中でChatGPTデスクトップアプリの更新もしたかったため、いったん安全に止めることにしました。Dotへ更新したいことを伝えると、それぞれのWorkで現在の状態を保存し、再開位置や残っている作業を記録しました。
アプリを更新してPC側の接続を確認したあと、その保存地点から作業を再開させました。単に「もう一度最初から調べる」のではなく、止める前の状態を残して、そこから続きを始めるところまで確認できました。
「一つ終わった」と「開発が終わった」は違う
AI技術室では、前日から進めていた画面整理を続けました。第三者が画面を見たときに、何を調査していて、何が確認済みで、次に何が残っているのか分かりやすくするための整理です。
表示項目を増やすというより、逆に情報を整理し、内部の実記録と公開用の表示を分ける方向で修正しました。修正後には操作確認、関連テスト、型確認、ビルドまで実行されました。ここまでは順調でした。
ところが、そのWorkが一度「最終検証完了」という状態になりました。画面整理という一つの仕事として見れば、確かに完了しています。ただ、Creer AI技術室という開発全体が終わったわけではありません。
そこでDotへ、次のような趣旨を伝えました。
AI技術室の方はもう進められることないのかな。私としては止まっていることがすごくきついというか、一番のリスクなんだけど。
するとDotは、「進められることがないと確認できたわけではない」と判断し、既存の開発計画から次に進められる実装・検証を選ぶ方針へ切り替えました。その後、AI技術室側のWorkは再び動き始めました。
ここは今回、かなり重要だと感じたところです。Workに一つの仕事を渡すと、その仕事が完了した時点で結果を返すのは自然です。しかし、継続開発では、一つの作業が終わったことと、案件全体で進められる仕事がなくなったことは別です。
人が開発していても同じです。画面修正が終われば、次は調査処理を直すかもしれません。テストを増やすかもしれません。記録を整理するかもしれません。
今回Dotには、「止まっていること自体をリスクとして扱う」という考え方を追加で伝えました。もちろん、判断待ちを無視して進めるという意味ではありません。それ以降は、一つの作業が一区切りしたあと、判断不要で進められる次の仕事を探す動きが見られるようになりました。
樋門側では、間違った経路を切って読解へ戻った
一方、樋門側では別の問題が起きました。前日から、受領済みの31版配筋図やDXF、既存の記録を使って、鉄筋番号と各図面の対応を追っていました。
ところが途中で、Workが以前確認していた、Google Drive for desktopでマウントした共有ドライブを再び読もうとしました。今回のローカルWorkからは正常に扱えないことが既に分かっていた場所です。社内NASについても、今回の作業ではアクセスしない方針にしています。
それにもかかわらず、Workが古い所在確認へ戻ろうとしました。結果としてアクセス拒否で止まりました。
ここで興味深かったのは、単純に「失敗したからもう一度試す」とはならなかったことです。Dot側で状況を確認すると、次の方向へ戻しました。
- マウントした共有ドライブへの再試行は不要
- 社内NASへもアクセスしない
- 既にローカルへ保存されている受領31版と作業記録を使う
- 保存済みの成果と再開位置から続きを行う
その後、樋門側のWorkはローカルにある資料から読解を再開しました。今回の午前中は、ずっときれいに進んでいたわけではありません。止まりましたし、間違った場所を見に行くこともありました。ただ、そこで案件全体が終わるのではなく、誤った経路を切り、保存済みの状態から別の進め方へ戻るところまで確認できました。
再開後は、31版の資料だけを使って、まだ確定できていない鉄筋の対応関係を順番に追いました。同じ鉄筋番号が平面図、側面図、断面図、加工図の複数箇所に出てくるため、単純に番号が同じだから同じ一本、と判断することはできません。
高さ、位置、引き出し線、加工形状、長さなどを照合しながら、確認できたものと、まだ根拠が足りないものを分けていきました。A22付近の図面関係、A25やA27の候補、A36・A37、A56、A71・A72など、Workが一度結果を返すたびに、Dotから次の読解範囲が渡されました。
途中では、既存記録との食い違いや、図面上の20mm程度の差なども出ています。そこを無理に補正して確定するのではなく、根拠が足りないものは保留したまま次へ進みました。AIが担っているのは、元請会社から受領した資料の整理・照合や、確認を求めるための材料づくりです。技術上の判断が必要なところをAIだけで確定させない方針も維持しています。
気づくと、DotからWorkへ次の指示が飛んでいた
今回、私が見たかったのはここでした。個別のWorkを開いて、私自身が毎回、
続けて。
と書く運用に戻っていないか。
画面を見ていると、Workが結果を返したあと、Dotから次の指示が送られ、再び作業が始まる場面が繰り返されました。樋門側では、ある範囲の読解が終わると、まだ資料内で確認できる別の箇所へ進みます。AI技術室側でも、画面整理が終わったあと、既存の開発計画から別の改善へ移りました。
少なくともこの時間帯については、私が2つのWorkを交互に見回って「次はこれ」「続けて」と入力し続けていたわけではありません。Dotが途中結果を受け取り、次に進める仕事をWorkへ渡していました。
再開したAI技術室では、画面だけではなく調査処理側にも作業が移りました。古い結果が残る問題や、取得した本文データの想定外の形によって処理が止まる問題などを修正しました。その後、テスト、型確認、通常ビルド、内部ビルドまで確認されました。この時点では全189テストが通過しています。
重要なのはテスト数そのものではありません。一つ前の「画面を整理する」という仕事が完了したあと、私が次の具体的な開発項目を指定しなくても、既存の開発計画から次に進められる仕事へ移ったことです。前回の記事で確認できていなかったのは、まさにこの部分でした。
11時台、確定できない解釈は人に1問戻ってきた
その後も樋門側の読解は続きました。11時台になると、31版配筋図の図面③にあるN-N・O-O断面と、図②B/CのA40～A45付近の対応について、Workだけでは確定できないところまで来ました。
ここでWorkは、図面上の位置だけから鉄筋の実位置を決めませんでした。N/Oの矢視について、元の指示が実物の断面位置を指定しているのか、それとも見え線や奥側の投影を含む見方を示しているのか、二つの候補を残しました。そのうえで、どちらの解釈を採用するかについて、私へ1問だけ確認を返してきました。
一方で、その判断を待たなくても進められるA55については読解を続けています。重複する矢先も、「矢先の数がそのまま鉄筋本数になる」とは扱わないよう整理していました。同じ画面にはAI技術室の現在地を確認する仕事もあり、Dot本体は「思考中」と表示されていました。
これは、朝に伝えた運用方針にかなり近いものでした。AIだけで進められるところは進め、本当に人の技術判断が必要になったところだけ人へ戻す。 不明点を勝手に確定せず、確認に必要な候補と根拠を整理して返してきたことに意味があります。
私へ戻ってきたことは、私が設計上の最終判断を単独で行うという意味ではありません。当社で確認できる内容か、元請会社へ判断を求める必要がある内容かを、人が切り分けます。AIが進めるのは、そのための図面照合と材料整理です。
「止まらずに仕事を続ける」といっても、AIが何でも勝手に決めればよいわけではありません。人が確認すべき境界まで仕事を進め、その境界を明確にして返してくれることの方が重要だと感じました。
午後には、Workが仕事を分け、結果を統合した
その後、もう一段試してみました。以前、樋門の開発をCodexで進めていたときに使っていたサブエージェントです。ここでは、親Workから個別の調査を受け持つ担当へ仕事を分ける仕組みとして使いました。
Dotへ、独立して確認できる作業についてはWork/Codex側でサブエージェントを使ってよいと伝えました。ただし、同じ判断対象を別々に確定しないこと、結果は親Workで統合すること、人の技術判断が必要な内容は私へ戻すことを条件にしました。
実際に親Workは、324と325に関する確認を2つの担当へ分けました。画面には「Review 324 endpoints」と「Review 325 changes」が並び、しばらくするとサブエージェントは「有効 0」「完了 2」になりました。
12:42:55には、親Workが「独立担当2件を統合」と報告しています。同じLibrary上の記録をversion 15へ更新し、324は2線が75.698mm短縮、325は緑線の分割と線種変更、と整理していました。
ただし、これで変更意図や実際の鉄筋配置まで分かったことにはしていません。図面の変更として拾えたことと、その変更が設計上何を意味するかは分け、「変更意図・実配置は未確認」と残していました。
さらに13:02には、その統合結果を受けたDotから親Workへ次の指示が送られました。追加の確認も、対象の筋符号、図の向き、引き出し線との関係を独立して調べられるなら分担してよい。ただし、変更意図そのものは推測で確定しない、という方針です。
今回、画面と報告で追えた役割は次のようなものでした。
| 担当 | 行ったこと |
|---|---|
| 私 | 進めてよい範囲と、人へ戻す判断の境界を伝える |
| Dot | 案件の状態を見て、親Workへ仕事を渡す |
| 親Work | 独立した確認を2担当へ分け、結果を回収・統合する |
| サブエージェント | 担当する変更点を個別に調べ、親Workへ返す |
| 親WorkからDotへ | 記録を更新して統合結果を報告し、Dotが次工程を指示する |
分担して調べた結果が親Workへ戻り、一つの記録へ統合され、その先の仕事につながる。 少なくとも今回の樋門開発では、そこまで一周するところを確認できました。
サブエージェントが見つけた変更を、そのまま設計上の確定にはしない。親Workで統合したあとも未確認事項を残し、Dotも同じ境界を次の指示へ引き継ぐ。並行して調べることに加えて、この判断の扱いが保たれたことも大きかったと思います。
人の回答も、次工程へ渡す材料になった
親Workは、2担当の結果をまとめて終わったわけではありません。私が回答したN/Oの解釈も取り込み、次工程へ渡せる参照データを作っていました。画面の報告では、6テストで確認し、13:10:26に保存しています。
これは、私の回答が一度の会話だけで終わらず、次の作業で参照する材料になったということです。ただし、6テストが通ったという報告だけで、設計内容の正しさ全体が保証されたとは考えていません。
資料に誤りがあるからこそ、そのまま照合を続けてほしい
そのあと、Workから「数量・加工との照合には加工図と数量表が必要」という確認が戻ってきました。ここで私は、次の条件を追加しました。
加工図と数量表は変わらず。一部間違いもあるけど、だからこそ、そのまま進めてほしい。
新しい資料がなければ作業できないという意味ではなく、既存の加工図と数量表を照合材料として使ってほしいという意図です。一部に誤りがあることも前提にしています。数量表に書いてあるから正解として図面を合わせる、ということではありません。
Dotは、加工図・数量表は変更なしとして保全済みの資料で照合を続け、資料に誤りがあることを停止理由にせず、図面との食い違いを根拠付きで洗い出す、と受けました。
「止まらない」といっても、無条件に勝手に進めてよいわけではありません。誤りを含む資料も照合材料に使い、正解扱いせず、不整合として根拠を残す。 この原則を伝えることで、その範囲の仕事を続けられるようにしています。誤った資料をそのまま成果品へ採用する指示ではありません。
14:45まで見ていると、私が伝えていることも、朝とは少し変わっていました。「A40を見て、次はA41を見て」という細かな作業の割り振りよりも、次のような判断原則が中心になっています。
- 人の技術判断が必要なところは確認を戻す
- 独立した確認はサブエージェントへ分けてよい
- 同じ対象を別々の担当が二重に確定しない
- 結果は親Workで統合し、未確認事項も引き継ぐ
- 資料の誤りは根拠付きの不整合として残し、進められる照合を続ける
15:58、両方の案件がまた止まっていた
このまま仕事が続くのかと思っていましたが、15:58に画面を見ると、AI技術室も樋門側も止まっているように見えました。私はDotへ、「どちらも止まっているようにみえる。なぜか？」と聞きました。
Dotは「はい、今は両方とも止まっています」と認め、PCは接続されており、接続切れが原因ではないと説明しました。そして、次のように振り返りました。
一部の判断待ちや一区切りを、案件全体の停止にしてしまっています。継続してほしいという指示に対して、私の進行管理が足りていません。
AI技術室には、公式ページだけを読む方式を製品コードへ組み込むかどうかの確認待ちがありました。樋門側には、数量Excel本体が未取得という条件がありました。ただ、どちらの案件にも、それらの条件に依存せず進められる仕事は残っていました。Dotは一部の保留を案件全体の停止として扱ってしまったのです。
朝にも似たことが起きています。AI技術室の画面整理が一区切りしたとき、次の開発へ移らず止まり、私が「止まっていること自体がリスク」と伝えました。その後は何度も次のWorkにつながり、午後にはサブエージェントを使った分担と統合まで進みました。それでも、同じ種類の停止がもう一度起きました。
Dotは、判断待ちの部分を保留しつつ、両案件の既存計画を見直し、依存しない仕事を具体化して進めると答えています。ただし、この時点で確認できたのは再開するという方針までです。実際にその後、自分で両案件を再始動したかどうかは、まだ確認していません。
一日の流れを振り返ると、止まり、方針を直し、仕事がつながり、分担と統合まで進んだあとに、また止まりました。この最後の停止も、今回の実験結果です。
実際に動かしたあとで、公式説明が具体的に見えてきた
ここまで実際の画面を見てから、改めてOpenAIのDotsに関する公式説明を読み直してみました。以下は、2026年10月2日に確認した説明です。
OpenAIはDotを「always-on agent」と説明しています。会話と会話の間も進捗を追い、次に何をする必要があるかを考え、必要に応じて一時停止や再開をする。人の判断が必要になったところでは、ユーザーへ確認を戻すという考え方です。
また、複数の仕事をバックグラウンドのエージェントへ分けて並行して進め、Dotが作成したタスクの結果を確認し、追加指示を送れることも説明されています。今回、2つの案件が別々のWorkとして動き、一つが結果を返すとDotから次の指示が入ったのは、この説明に近い動きでした。ただ、画面だけで内部の実装まで確認できたわけではありません。
一方で、ローカルPCを使う場合には条件があります。公式説明でも、接続したPCのファイルやツールを使う仕事では、そのPCがオンラインで、ChatGPTアプリが動いている必要があるとされています。前日の夜にPCがスリープしてローカル作業が止まったのも、この条件と整合します。
Dot自身はクラウド側にいて、PCがオフでもクラウド上の仕事は進められます。ただし、ローカルで動くタスクが自動的にクラウドへ移るわけではありません。今回のようにPC内の資料や開発環境を必要とする仕事では、両者を分けて考える必要があります。
面白かったのは、公式説明を先に読んで「こういう機能なのだろう」と考えたときよりも、実際の2案件を動かしてみたあとで読み返すと、
ああ、この「仕事をつなぐ」動きのことを言っているのかもしれない。
と、ようやく意味が具体的に見えてきたことでした。
朝から午後まで、一つのWorkが走り続けたわけではない
ここは誤解のないようにしておきたいところです。朝7時半過ぎから15:58までの時間は、観察した時間の幅です。一つのWorkがその間ずっと連続で処理を続けたわけではありません。
実際には、数分から十数分程度の作業が何度も一区切りしています。結果が返り、次の仕事が選ばれ、またWorkが動く。途中にはエラーもありました。アプリ更新のための停止もありました。間違った保存先を見に行くこともありました。さらに最後には、進められる仕事が残っているのに両案件とも止まっていました。
今回見たかったのは、Workそのものの連続稼働時間ではありません。一区切りになったWorkの次を、誰がつなぐのか。 そこです。
ここまで見ると、「Dotsに任せれば自動で開発し続ける」と書きたくなるところですが、今回の結果からはそうは言えません。実際、私も途中で何度かDotへ話しかけています。「止まっていること自体がリスク」という方針を追加し、アプリ更新のタイミングを伝え、午後には再び止まった理由を尋ねています。
技術判断や最終承認については、今も人が行う前提です。人間が完全に離れて何日も勝手に開発が進むことを確認したわけではありません。前回気になっていた通知の開封と再開の関係も、今回の観察だけで仕組みまで切り分けられたわけではありません。
OpenAI自身も、実行が完了しただけでは、依頼した結果の達成や受け渡しを確認したことにはならないと注意しています。出力と報告されたエラーを確認する必要があります。今回の189テスト通過も、樋門資料の技術上の判断まで正しいと保証する数字ではありません。
ただ、従来のWorkの使い方とは明らかに違うところもありました。私が担当していた「結果を見る → 次の仕事を考える → Workへ『続けて』と送る」という細かな中継作業の一部を、Dotが担当した場面があります。仕事をつなぐ能力は見えました。しかし、安定してつなぎ続ける進行管理までは確認できませんでした。
人は、判断原則を伝え、止まっていないかも見る
1本目の記事を書いたとき、Dotは「複数案件をまとめて見る上位の担当者」のように見えると書きました。今回、その感覚はさらに強くなりました。
朝の時点で確認したかったのは、人が「続けて」と言わなくても、一区切りしたWorkの次へ仕事がつながるのか、ということです。午後には、その内側で仕事を分け、結果を回収・統合し、人の回答も次工程へ渡す動きまで見えてきました。
私が見る場所も変わりつつあります。個々のWorkへ毎回次の作業を指定するより、どこまでAIだけで進めてよく、どこから人へ戻すのかを伝える。資料の食い違いをどう扱い、何を根拠として残すのかを決める。この方が、今回の運用には合っていました。一方、方針を渡しただけで進行を完全に任せられるわけでもありませんでした。
技術上の最終判断や元請会社への確認がなくなるわけではありません。むしろ、そこへ戻す材料をAIが整理し、判断を待つ間にも独立して進められる仕事を続ける形です。
この記録を書いた時点でも、2案件の開発は完全に終わっていません。樋門側には、31版の資料だけでは確定できない箇所があります。32版の資料が受領されなければ進められない部分もあります。AI技術室にも、まだ改善できる項目があります。
今回午後まで仕事がつながったからといって、毎回同じように動くとも限りません。サブエージェントを使えば、いつでも速くなると確認できたわけでもありません。それでも、第2回の最後に残していた問いから、少なくとも一歩先まで見ることができました。
止まることもある。間違うこともある。そのときに保存した現在地へ戻り、進められる仕事を探し、個別のWorkへ次の指示を出せた場面はありました。しかし、午後に再び止まったときは、私が問いかけるまで案件全体の停止を解けていませんでした。
Dotsの面白さは、仕事を途中で切らさずにつなぐ役割にあるのかもしれません。そして人は、仕事を一個ずつ渡すところから、AIが仕事を進めるための判断原則を伝える側へ少しずつ移っています。ただ、今はまだ「人が監視しなくてよくなった」とは言えません。人が状態を確認する頻度を、どこまで下げられるのかを試している途中です。
15:58にDotが示した再開方針が、その後、本当に自分での再始動につながるのか。それが次の観測点です。まだ使い始めて2日目なので、もう少し、このまま動かしてみます。