タスクは Dot に任せ、作業は Codex と進める：開発者の新しいコラボレーションの形

OpenAI の開発者体験チームの Dominik Kundel は、これまで Codex の設定にかなりの労力を注いできました。メモリで好みを記録し、プラグインを導入し、自動化を設定し、さらには全体の統括用に「参謀長」スレッドを設けるほどでした。しかし、しばらく Dots を使ってみて彼が気づいた最も顕著な変化は、個々のフォローアップ手順を自分ですべて覚えておく必要がなくなったことでした。

コードが書けることと、その後のあらゆる作業を覚えておいてくれることは別物です。 筆者の従来のワークフローは次のようなものでした：

Appshot（アプリ画面のスナップショット）や Slack メッセージのリンクを Codex に渡し、機能を実装させ、デプロイ状況を監視して結果を Slack に返信するよう指示します。しかし、新しい要望が出るたびに、機能やリリース計画の変更を追跡するための自動化を個別に設定するよう指示しなければならず、毎回同じセットアップを繰り返す必要がありました。

本当の負担は、新しい仕事が生じるたびに自分で指示を組み立て、フォローアップの方法を追加で構成しなければならない点にありました。

現在では、筆者は同じ Slack スレッド内で直接自分の Dot を @メンション できます。Chopper はタスクを引き受けて問題に対処し、元のスレッドに戻って結果を報告するだけでなく、リリースに関する変更にも注意を払い、筆者にリマインドしてくれます。これにより、依頼、実行、報告、その後のフォローアップが一連の流れとしてつながり、新しいタスクが来るたびに筆者自身が一からそのプロセスを組み立てる必要がなくなりました。

そして Dots の登場は、まさにこのタスク整理とフォローアップの負担を引き受けるためのものです。Codex を置き換えるのではなく、同一のオープンソース Codex Agent 実行フレームワーク（harness：モデルがツールを呼び出しタスクを進行させるランタイムシステム）を基盤として、タスクを引き継ぎ、継続的にフォローアップする役割を担います。

このことは、すでに Codex をカスタマイズし終えている人でも Dots を活用できる理由でもあります。Dot はアカウントに接続済みの ChatGPT / Codex プラグインを引き継ぐことができ、それらのプラグインを使って情報を検索したり、既存のツールやサービス内で作業を進めたり、既存の関連コンテキストを活用したりできます。タスクを依頼する入り口をひとつ増やすためだけに、以前の設定をすべてやり直す必要はありません。

Dot は継続的にタスクを委任できる個人向け Agent

簡単に言えば、Dot は GPT-6 Astra モデルで動作する常駐型の専属アシスタントです。筆者の執筆時点では作成できる Dot は1つのみですが、カスタム名や専用の外観を設定でき、ペットの写真をアバターとして使うことさえ可能です。

例えば Dominik Kundel は、自身の Dot に Chopper と名付け、黒い小さな帽子をかぶったオレンジ色の小さな獣の姿にカスタマイズしました。

Dot の特徴は、常駐性とマルチデバイス連携にあります。専用の Handle（例えば @tibo-alfred や @yourname-dot）を持っており、作業を始める前に具体的な Codex スレッドをわざわざ選ぶことなく、直接タスクを割り当てることができます。

チャットウィンドウを切り替える対話から、タスクの委任方法の変革へ

Codex を直接使用する形から Dot と協調する形への移行は、主に3つの側面での変化として表れます：

1. マルチチャネルの連続性：場所や手段を問わず対話し、コンテキストが途切れない

普段、同僚や家族と連絡を取るとき、私たちはチャットアプリ、通話、SNS を行き来することがありますが、議論の背景は維持され、毎回ゼロから説明し直す必要はありません。Dot も同様の連携が可能です：

• 場面をまたぐ引き継ぎ：同僚が Slack でバグを報告すると、筆者はそれを自身の Dot（Chopper）に転送し、Chopper は必要な情報を検索して作業を開始します。帰宅途中、筆者は Chopper に直接電話をかけてそのバグについて話し続けたり、まったく別の新しい話題について議論したりできます。オフィスに戻ると、筆者はデスクトップ版チャットでやり取りを継続することも、Chopper が完了した作業を直接レビューすることもできます。プロセス全体を通じて、向き合っているのは同一の Dot です。同じ Dot はチャネルをまたいだ関連コンテキストを利用できますが、Slack と ChatGPT のメッセージが自動的に相互コピーされるわけではありません。また、新しく委任されたタスクもそのタスクの達成に必要なコンテキストのみを受け取り、すべての会話履歴が自動的に渡されることはありません。ダイレクトメッセージの情報を他者に共有する場合にも、依然としてユーザーの承認が必要です。
• 複数チャネルの同時並行利用：Dot と音声通話を行っている最中でも、テキストによるコミュニケーションを同時に併用できます。例えば Chopper は通話の途中で筆者が確認するためのテキストやコンテンツを送信でき、筆者は電話を切ることなく画面上でテキスト返信したりリンクを送信したりできます（筆者はこの方法で ChatGPT Space 内で記事を推敲しました）。通話を続けながら、Dot は別のタスクが完了した際にリマインドを送ったり、緊急の事態が発生した際にプロアクティブに通知したりすることも可能です。
• メモリとノートの仕組み：既存の ChatGPT メモリや関連会話を利用できることに加え、Dot は Codex 本来の会話圧縮（compaction）メカニズムとは別に、独立したプライベートなメモ用ノートツールを備えています。Dot は重要なノートを記録し、適切なタイミングで自ら起動して関連テーマに関するバックグラウンド調査を行い、これによりユーザーの業務の詳細や協業関係を次第に把握していきます。プライベートノートと会話圧縮は異なるツールであり、OpenAI はプロアクティブな調査やプライベートノートをモデルの学習に直接使用することはありません。ただし、それらに含まれる情報が対象となる会話やタスクに持ち込まれた場合は、ユーザーのデータ設定が適用されます。

2. 対話を続けながら、各タスクを最適な環境へ振り分ける

多くの開発者が最も気にするのは、Dot と Codex の基盤環境がどのように役割分担されているかという点です。

実際、Dot 自体は単一のデバイスに制限されません。ユーザーと継続的に対話しながら、ひとつの Dot がサブ Agent や独立したタスクを並行して起動し、後から結果を集約できます。ユーザーはいつでも対応する Codex スレッドを開いて Codex と直接共同作業することも、Dot に引き続き調整を任せることもできます。例えば移動中に電話でアイデアを出しながら、Dot に直接 Codex Cloud のクラウドタスクを起動させることも可能です。

これら3つの計算環境は、それぞれ異なる役割を担っています：

Dot 自身のクラウド PC（Dot's PC）

Dot はクラウド上に独立した仮想マシンとブラウザを保持しています。クラウドタスクはユーザーの PC の電源を切った後も実行を継続でき、セッションの合間にもマシンの状態が維持されます。情報検索だけでなく、Blender、FreeCAD、GIMP、Godot、Kdenlive などのエンジニアリングおよびマルチメディアソフトウェアがプリインストールされています。クラウドブラウザは独立したセッションを持ち、ユーザーのローカルブラウザのログイン状態を引き継ぐことはありません。

ユーザーのローカル PC（Your PC）

デスクトップアプリ経由でローカル PC への接続を承認すると、Dot はローカルのファイル、ツール、ログイン済みのローカルブラウザ環境（コンピュータ利用能力を含む）を利用できるようになります。これには、ローカル PC がネットワークに接続され、ChatGPT クライアントが起動・実行されたままである必要があります。ローカル PC を接続したからといって、あらゆるアプリのすべての会話が Dot に開放されるわけではありません。

Codex クラウド環境（Codex Cloud）

特定のリポジトリや設定を必要とするコーディングタスクについては、Dot はユーザーがあらかじめ構成しておいた Codex クラウド環境内で独立したタスクを立ち上げることができます。このようなクラウドコーディングタスクも同様に、ローカルデバイスがオフラインの際にも実行を継続できます。

実際の運用において、Dot はユーザーの習慣に基づいてその好みに次第に適応していきます。例えば筆者個人の場合、バックエンドの修正や素早いテキスト調整はクラウドに任せ、大規模なフロントエンド UI の変更はローカルのノート PC で実行することを好みます。筆者によれば、Dot は日々のやり取りを通じてこうした好みを段階的に理解し適応していくとのことですが、ここで述べられているのはあくまで彼自身の使い方です。

筆者はさらに、考えられるシナリオとして次のような例を挙げています：ローカルの Codex で Dot を介してタスクを実行している最中に、カレンダーからまもなく移動時間になることが分かると、Dot は作業をクラウドに切り替えて継続することを提案するかもしれません。Dot が考慮するのはタスクがどこまで進んだかだけでなく、次にどの環境であれば作業を続けられるかという点も含みます。ただし、ここで述べているのはあくまでプロアクティブな提案であり、実際の切り替えにはクラウドタスクを改めて割り当てる必要があり、既存のタスクや実行状態のすべてが自動的に移行されると解釈すべきではありません。

3. 新しいメッセージと過去のタスクを結びつけ、次に行うべきアクションを促す

プロアクティビティ（Proactivity：能動性）は、Dot がもたらす際立った違いです。ユーザーから直接指示された事柄以外にも、Dot は連携しているアプリやツールの情報をバックグラウンドで組み合わせ、人間の指示を待たずに自発的に作業の進捗をフォローアップできます。例えば、Slack の新しいメッセージや議事録内の新たな決定事項が先週議論した事柄に関連している場合、Dot はそれらを紐づけてユーザーに注意を促すことができます。

• ケース1：PR デプロイの追跡 筆者はかつて、PR が本番環境にデプロイされる全プロセスを追跡し、修正の再テストが可能になったタイミングで自分に知らせるよう Chopper に依頼しました。これにより、人間が手作業でステータスを何度も確認する手間が省けました。筆者が求めていた肝心のアップデートは、再試行が可能になったという確認そのものだったからです。
• ケース2：カンファレンス会場での潜在的リスクの事前警告 技術カンファレンス（DevDay）の期間中、筆者はオープニングキーノートで生じたトラブルが自身のセッションの技術デモに影響しないかを Slack 上で調査していました。Chopper はこの動きに気づくと同時に、筆者がまだ把握していなかった別のインシデントが当時発生していることも検知しました。Chopper は障害の状況、プレゼンのスクリプト、スケジュールをクロスチェックし、デモ内の該当箇所を確認するよう筆者に促しました。

• ケース3：フィードバックの自動調査と修正検証 Dots チームのあるエンジニアは、自身の Dot にさらに一歩進んだ権限を付与しました。フィードバック用チャンネルを監視するだけでなく、寄せられた問題を能動的に調査し、Codex による修正タスクを立ち上げ、CI（コードコミット後に自動実行されるビルドおよびテスト）をチェックして失敗項目に対処させるというものです。重大な問題に直面した場合、Dot はエンジニアが介入できるようフラグを立てます。これらのタスク自体はすべて Codex スレッドであるため、エンジニアはいつでも直接スレッドに入って作業を引き継ぐことができます。

どの作業を委任でき、どの作業を自ら判断すべきか？

AI Agentにこれほど高い自由度を与えると、制御不能になって勝手にコードを書き換えたりメッセージを誤送信したりしないでしょうか？

肝心なのは、Agent が何を「調査」しているのかと、実際に何を「実行」することを許可しているのかを明確に区別することです。

1. デフォルトの保護、プロアクティブな調査、およびアクションの審査

Dot がバックグラウンドで行うプロアクティブな調査（Proactive Research）は、読み取り専用（リードオンリー）の性質を持ちます。この調査に使用されるツール自体には、メッセージを送信したり、アプリのコンテンツを変更したり、ブラウザや PC を操作したりする機能はありません。アカウントや共有情報に影響を与える可能性のある後続のアクションについては、認可と自動審査を経る必要があります。システムはユーザーの指示、アプリの権限、カスタムルール、および組み込みの安全メカニズムを組み合わせて、そのアクションを即時実行可能とするか、ユーザーの承認を求めるか、あるいはユーザー自身による手動操作を必須とするか（パスワード変更など）を判断します。

Dot を Slack などのメッセージングチャネルに接続しただけでは自動的に監視が始まるわけではなく、監視すべきチャンネル、イベント、および継続して果たすべき職務を明示的に指定する必要があります。進行中の長期フォローアップタスクについて、Dot は個々のフォローアップごとに固定スケジュールを個別に設定することなく、いつ作業を一時停止し、いつ起動して作業を再開するかを自律的に決定できます。ただし、決まった時刻に繰り返し実行するタスクについては、スケジュール設定を明示的に保存しておく必要があります。

2. 事前確認が必要なアクションをルールで定義する

カスタムルールは、特定の長期的なアクション要件に対して提供される任意の制御設定であり、特定のアクションに対して設定画面で4つの動作モードを選択できます：

• 確認なしでアクションを実行（Take action without asking）：承認を求めずに、指定されたアクションを直接実行します。
• 指示があった場合のみ実行（Take action when you say so）：ユーザーが明示的にその操作を要求した場合は直接実行し、それ以外の場合はアクションを起こす前に確認を求めます。
• 実行前に確認（Ask before taking action）：指定されたアクションを実行する前に、必ず事前に承認を求めます（顧客へのメッセージ送信など）。
• ユーザーに委ねる（Hand off to you）：そのアクションはユーザー自身の手で完了させるようハンドオフします（共有プロジェクトファイルの削除など）。

カスタムルールは Dot が遵守するよう努める指示ですが、抜け漏れが生じる可能性は依然として残ります。これらのルール自体がアプリや PC へのアクセス権限を付与することはなく、組み込みのセキュリティ保護要件を迂回することも、特定の必須確認（保存されたパスワードを用いた新規ログイン時の認証確認など）を免除することもできません。

3. コントロール、制御の引き継ぎ、およびタスクの終了

クラウド PC 内の操作を引き継ぐ必要がある場合は、該当するクラウド PC を開いて Take over（制御を引き継ぐ） を選択し、マウスやキーボードを使って直接操作できます。作業が完了したら Return control（制御を戻す） を選択して Dot に作業を続行させます。

タスクを一時停止または終了する必要がある場合、各コントロールの適用範囲はそれぞれ異なります：

• Pause（一時停止）：Dot が現在実行しているメインタスクのみを停止します。これは全体に対する緊急停止ではなく、割り振り済みの委託タスクをすべて停止することも、将来の予定スケジュールを取り消すこともありません。
• Activity（アクティビティパネル）：Dot から割り振られた独立したサブタスクを停止する必要がある場合は、Activity パネルで該当するタスクを開き、個別に確認して終了させる必要があります。
• Scheduled（スケジュールパネル）：定期的な繰り返しタスクを取り消すには、Scheduled パネルに入って個別に無効化または削除する必要があります。
• 通話とタスクの分離：音声通話を終了しても音声コミュニケーション自体が切断されるだけであり、割り当て済みのバックグラウンドタスクは引き続き実行可能です。

利用枠のポリシーと導入手順

提供範囲と利用枠

• 提供範囲：現在、対象となるアカウントに向けて段階的にロールアウトされています。Pro 100、Pro 200、Pro 500（18歳以上、かつ欧州経済領域、英国、スイス以外の地域に居住するユーザー向け）が含まれます。Business Premium および Enterprise は全世界で段階的に展開されています（Enterprise はデフォルトで無効化されており、ワークスペース管理者の有効化が必要です）。
• 利用枠の消費ルール：Dot との対話は ChatGPT の利用制限にはカウントされません。一方、Dot が Work や Codex 内で起動・管理する作業タスクは、通常どおり該当製品の利用制限にカウントされます。ユーザーのサブスクリプションプランにはディープワーク枠が含まれており、提供開始後の初月には拡張された利用枠が提供されます。筆者が述べる「ほぼ無制限」とは、主として Dot 自体との日常的なやり取りが通常の利用枠を消費しないことを指しており、バックグラウンドの作業タスクを無制限に消費できると解釈すべきではありません。
• 利用開始の窓口と接続要件：Dot の作成はデスクトップアプリまたはデスクトップウェブ版で行う必要があり、モバイルウェブ版での作成はサポートされていません。作成完了後は、対応するアップデートが適用されたモバイルアプリ上で同じ Dot を利用できます。ローカル PC の接続は独立した設定であり、ローカル PC を接続していなければモバイルアプリで Dot と対話できないというわけではありません。

推奨される段階的な導入アプローチ

すでに自前で循環型のフォローアッププロセス（loops）を構築していたり、1つの親スレッドで複数の作業スレッドを統括（thread of threads）していたりする場合、タスクの整理やフォローアップに関する課題の一部はすでに解決できているはずです。筆者も認めているとおり、そうしたユーザーは短期的には Dots の恩恵をすぐには実感しにくい可能性があり、製品もまだ初期段階にあります。

導入を検討するなら、筆者が引用している Claire Vo の「アンチ To-Do リスト（Anti-to-do-list）」を参考にするとよいでしょう。自分自身で繰り返し行い、何度も目を光らせている作業を洗い出し、1つずつ Dot に教えていくアプローチです。目的は Dot にさらに長いリストを作らせることではなく、プロセス、成果物、権限が明確になった後で、自分自身が担うべき反復作業を減らすことにあります。具体的には次のように進めます：

1. 高頻度で明確な検収基準があるタスクを選ぶ：1日または1週間に複数回発生し、どのような結果であれば合格かが明確に分かっているタスクを選びます（インターフェース変更の定期的な比較や、特定のチェック項目のフォローアップなど）。
2. 手順を実演し、一緒にブラッシュアップする：Dot に操作プロセスを一度実演して見せ、一緒に結果を調整・改善した上で、正式にタスクを委任します。
3. 十分な資料を提供し、許可するアクションを明確にする：関連リンクや必要なアクセス権限を提供し、処理を許可する範囲を会話の中で明確に伝えるか、カスタムルールを通じて確認を求めるタイミングを設定します。
4. 協調関係を整理する：筆者がまとめたコラボレーションのあり方は、「タスクは Dot に委任し、直接の議論が必要なときは Codex と協調する（delegate to my Dot, collab with Codex）」 というものです。Dot は日常の些細な雑務にとどまらず、複雑なタスクも引き受けることができます。踏み込んだ議論を行ったり、特定の問題についてペアプログラミングのように調査したりする必要がある場合は Codex と直接対話し、日常的な継続追跡、複数タスクの割り振りや進行の調整は Dot に委ねます。