ChatGPT Dotsに2つのローカル開発案件を任せてみた――進捗管理ではなく、実際の開発まで任せる
ChatGPT Dotsに、樋門設計のAIエージェントとCreer AI技術室の開発を渡しました。PC上の記録から現在地を読み、別々のWorkで調査・変更・テストへ進んだ初日の記録です。権限や継続動作など、まだ分からない点も残します。
OpenAIから新しく「Dots」が出てきました。公式の説明では、Dotは継続的な仕事を引き受け、複数のタスクを別々に進められるとされています。説明を読んでも、正直なところ、実際の仕事でどこまで任せられるのかは分かりませんでした。
で、実際の仕事では何を任せられるのか？
ちょうど当社には、ChatGPTを使って継続開発している案件が複数あります。そこで、作ったばかりのDotへ進行中の2つの開発案件を渡してみることにしました。
これはDotsの機能を網羅する記事ではありません。2026年10月1日に、当社のPCにつないで数時間動かしたときの記録です。試したいことがまだ残っているので、まずは第1回として、最初に考えた役割と、実際の動きを残します。
渡したのは、性格の違う2つの開発案件
一つは、樋門設計に関するAIエージェントの開発です。配筋図、DXF、既存設計資料などを扱い、配筋情報の整理や照合、検証方法を試しています。
もう一つは、Creer AI技術室です。AI関連の技術情報を集め、候補を整理し、人が選んだものを追加調査や試作につなげる仕組みを作っています。
これまでは、それぞれ別のChatGPT ProjectやWorkで開発していました。コードやデータの実体は、案件ごとに分けたPC内のフォルダーにあります。AI技術室の開発フォルダーには、AGENTS.md、CURRENT_STATUS.md、CODEX_HANDOFF.mdといった指示・現在地・引き継ぎの記録も置いています。公開上、フォルダーの実際の場所は伏せます。
つまり、ChatGPTの会話だけが開発の記憶ではありません。案件フォルダーを読めば、途中からでも現在地を復元できるようにしてきました。この作り方が、今回の実験で思った以上に効きました。
最初は「統括と進捗管理」を任せるつもりだった
初めに考えたDotの役割は、2案件の統括でした。それぞれを混ぜずに、「今どこまで進んだか」「次は何をするか」「私の判断が必要なのはどこか」を見てもらう。いわば、AIのプロジェクトマネージャーです。
既存の開発Workから現在地をまとめ、Dotへ渡してみました。しかし途中で、引っかかりました。
これでは結局、私がWorkからDotへ引き継ぎを運んでいるだけではないか。
Dotが継続して動いても、毎回こちらが情報を集めて渡すなら、私の仕事はあまり減りません。そこで、Dot自身に実際の開発環境を見てもらうことにしました。
PCのフォルダーから、現在地を拾わせてみた
OpenAIの案内には、DotにPCへのアクセスを許可すると、そのPCを使うローカルのWorkやCodexのタスクを作れるとあります。今回は当社の開発用PCを接続し、2案件それぞれのフォルダーを確認させました。
AI技術室では、指示や現在地のMarkdown、JSON、調査記録などを読み、開発状況を確認できました。樋門側でも、配筋に関する記録、PDF、DXF、照合資料などを見ていきました。
ここで分かったのは、長い引き継ぎ文を毎回書かなくても、ローカル側に現在地を復元できる情報があれば、そこから状況を拾わせられるということです。少なくとも、今回の2案件ではそこまでできました。
進捗管理だけなら、少しもったいない
フォルダーを確認し、案件の状況まで把握できるなら、進捗を見るだけにとどめる必要はないのではないか。そう考えて、途中でDotへの依頼を変えました。
人の技術判断や最終承認が必要なことは確認する。そのうえで、決まっている方針の範囲なら、調査、コード変更、テスト、検証、記録更新まで進めてよい。一方の案件が私の判断待ちになったら、もう一方で進められる作業を探してよい、と伝えました。
すると画面上では、樋門案件の受領資料の確認と、AI技術室の現在地の確認が、別々のWorkとして動き始めました。同じDotに渡した2案件が、それぞれの作業として並行して進む様子が見えます。
私は個々のWorkへ細かな開発指示を出していません。Dotへ任せる範囲を伝え、Dotから個別のWorkへ仕事が渡りました。私が各Workを行き来して「こっちは次に何をする」と伝えていたときとは、使い方が変わります。
提案だけでなく、ファイルの変更とテストまで進んだ
「状況を読みました」「次はこうしましょう」という提案だけで終わっていないか、実際の結果も確認しました。
樋門側では、受領した資料と図面の対応関係を整理し、追跡・検証用のJSONやスクリプト、検証結果のファイルが作られました。PDFとDXFを確認しながら記録を拡張し、テストを実行したことも確認しています。ただし、テストを通過したことだけで設計上の照合結果まで正しいとは言えません。そこは別に確かめる必要があります。
AI技術室側でも、既存の調査処理を調べ、取得できていない記事を「確認済み」にしない処理や、問い合わせ条件を広げる修正を進めました。こちらも、変更後の動きと運用への反映は引き続き確認します。
少なくとも初日は、Dotが案件を振り分け、その先のWorkが実際のファイル調査、変更、テストへ進むところまで見られました。ここで、Dotを単なる進捗確認役として考える必要はなくなりました。
2案件を混ぜずに扱えたことも大きかった
樋門設計とAI技術室では、目的も資料もコードも違います。一つのDotへ両方を任せて、情報が混ざらないかは気になっていました。
今回観察した範囲では、Dotは2案件を上位で把握しながら、実作業を別々のWorkへ分けていました。Dot自身へ細かな開発履歴をすべて抱え込ませるのではなく、Dotが全体を見る、Workが個別に動く、案件フォルダーに開発の記録を残すという役割分担です。
これが長期的にも成り立つなら、一つのチャットに開発の全履歴を詰め込まなくても済むかもしれません。以前、同じチャットを使い続けることと、AIが必要な状態を復元できることは違うと考えたことが、今回は実際の開発フォルダーにつながりました。
初日には、できなかったことも残った
PC内のローカルフォルダーは確認できましたが、Google Drive for desktopでマウントしたドライブや社内NASには、同じようにはアクセスできませんでした。接続や権限のどこが境界なのかは、まだ切り分けていません。
また、Dotから作られたWorkが作業用の成果物を作れても、元の案件フォルダーへ反映する段階で権限に止められる場面がありました。既存Workへ追加指示を送ろうとして、Invalid turn/start params: AbsolutePathBuf deserialized without a base path というエラーも出ました。
以前から当社環境で確認しているProjectとLocal Workのエラーとの関係も気になります。ただし、同じ原因だと確認できたわけではありません。権限とエラーについては、次の検証で分けて確かめたいところです。
「続けて」と言う回数は減るのか
これまでWorkでは、作業が一区切りつくたびに私が結果を読み、「続けて」と送る場面が少なくありませんでした。今回はDotへ2案件を任せ、しばらく手を出さずに見ていました。
2つのWorkが動き、途中結果がDotへ戻り、私の判断が必要なところで通知が来ました。さらにこのあと、あえて「続けて」と言わずに放置してみました。
すると、10〜20分ほどでWorkは一区切りし、Dotに通知が来ました。通知を開かずにいる間は、次の動きは見られませんでした。しかし、通知を開くと、こちらが新しい指示を送っていないのにWorkが再び動き始める場面がありました。
通知を開いたことが再開の条件だったのか、別の処理が重なったのかは分かりません。公式資料には、Dotが仕事を一時停止して後から再開し、並行するタスクを扱えると説明されています。ただ、今回の再開が具体的にどの仕組みによるものかまでは確認できていません。
初日に見えた役割と、次に確かめたいこと
使い始めてまだ数時間ですが、Dotsは私が最初に想像した「長く覚えてくれるチャット」とは違って見えました。今回の使い方では、2案件の状況を見て仕事を渡し、必要なときに私へ判断を求める上位の担当者に近い存在でした。
Dotを継続的な担当にする。個別のWorkに実作業を任せる。案件フォルダーに現在地と成果を残す。初日は、その形で2案件を動かせました。
ただ、ファイルへの書き込み権限、社内ストレージとの境界、Workが止まった後の再開には、まだ分からない点があります。この記事は「Dotsへ任せれば開発が自動で回る」という結論ではなく、進捗管理のつもりで渡した仕事が、実際の開発にまで進んだ初日の記録です。
では、最初から「通知を開くことすら待たず、判断が不要なら続けて」と指示したら、動きは変わるのか。これは次の記事で整理します。