OpenAI dotsに、自分の仕事をどう自動化させるか？

AIに頼んだ作業、チャットを閉じたところで止まっていませんか？ 9月29日に発表されたOpenAI dotsは、会話が終わっても専用のクラウドコンピューターで仕事を進め続けるエージェントです。自動化を任せるなら、何を渡し、どこで人が止めるかを先に決めておくと、届いた成果物の扱いで迷いません。

dotsは、どこまで仕事を自動で回してくれるのか？

公式の記述では、dotはそれぞれ専用のクラウドコンピューター、専用のブラウザー、アクセス権限のための専用IDを持っています。OpenAIはこれを「新入社員に用意するものとほぼ同じ環境」と例えています。dotは必要ならコードを書き、テストもします。

私の見立てでは、ここでの発想の転換は、質問する相手から、権限を渡して任せる相手に変わることです。

チャットとの差が出るのは、会話が終わったあとです。dotは別のプロジェクトを進めている間も新しいタスクに自律的に取りかかり、スレッドの管理や手順の指示は要らないと公式は書いています。連絡の窓口はChatGPT、Slack、Teams、音声通話などで、どのチャネルでも文脈が引き継がれます。dotの側からも、進捗の報告や判断の依頼が届きます。

私はまだdotsを実機で動かしていません。この記事では、事実はOpenAIが公式に書いている内容に限り、コードを書いてPRをレビューする人の仕事への読み替えは「私の見立て」などの言い回しで分けて書きます。

公式の5つの例から、自動化を頼みやすい仕事は3つ

公式ページは、開発者、ローンチ責任者、科学者、営業責任者、コンテンツクリエイターの5つの使い方を挙げています。私の見立てでは、エンジニアが自分の仕事に写しやすいのはこのうち3つです。選ぶ基準は2つで、入力の置き場所が決まっていること、出口を自分の目で判断できることです。

顧客フィードバックから、動画つきのPRまで

公式の例では、dotは顧客フィードバックから繰り返し出てくる要望を見つけ、小さな改善やバグ修正を実装してテストし、変更点を示す動画つきのレビュー可能なPRを届けます。OpenAI社内でも、Slackにバグ報告が来るとdotが調査を始める使い方をしていると紹介されています。

渡すのはフィードバックが集まる場所とリポジトリで、出口はPRです。公式が「小さな」と書いている点が肝心で、差分が数ファイルに収まる修正から任せるのが筋だと私は見ています。

顧客要件を製品ドキュメントと照合し、連携機能のPoCを作る

営業責任者の例では、技術審査中の法人案件で、顧客要件と取引履歴を製品ドキュメントと照合し、未検証の項目を特定して、重要な連携機能のPoCを作ります。

エンジニアに置き換えると、顧客から届いた要件一覧を自社のAPIドキュメントと突き合わせる仕事です。価値が大きいのはPoCより手前の「未検証の項目リスト」のほうで、これは読むだけで作れます。

新データが届くたびに、分析を再実行して図表を更新する

科学者の例では、dotは研究上の問いと評価方法を学び、新しいデータが届くたびに分析を再実行します。予想外の結果が出れば調べ、図表を更新し、人が確認すべき点を知らせてくれます。

週次のパフォーマンス計測や、リリース後のエラー率の集計に写せます。渡すのはデータの置き場所と「何を異常とみなすか」の基準で、出口は更新されたグラフと短い確認メモです。

ローンチ資料とSNS投稿の下書きの例を外したのは、成果物を承認するのがマーケティングや編集の担当者で、エンジニアが出口を握れないからです。

自動化の出口に届くPRを、レビューする側は何を見るのか？

変更点を動画で見せてくれるPRが届いたら、動いているのを見てそのままマージしたくなりませんか？

公式ページには「dotは間違えることもあるため、重要な影響を伴う作業は必ず確認してください」とあります。私の見立てでは、動画は「この画面ではこう動いた」という証拠です。新人が「動きました」と見せてくれるデモと同じで、承認の代わりにはなりません。映っていない入力で壊れていないかは、動画からは分からないからです。

レビューの前に確認したいのは、次の3点です。

• 差分が依頼の範囲に収まっているか。頼んでいないファイルに手が入っていないか
• 動画に映った操作以外のケースまで、テストが追加されているか
• 作業の途中で、承認を求められた操作があったか

途中の経緯を知る手がかりになりそうなのが、公式のいうアクティビティビューです。バックグラウンドで進んだ作業を確認でき、指示の出し直しもできます。PRの差分だけを見るより、そこにたどり着いた経路まで見たほうが判断は速くなります。

自動化の線引きは、許可と承認とブロックの3つ

新しく入ったメンバーに、初日からmainへの直接pushを許すチームはあるでしょうか？ dotsの専用IDに渡す権限も、同じ感覚で切るのが現実的です。

公式の記述では、dotがアクセスするアプリはユーザーが選び、権限はChatGPTの既存のアプリ管理設定から与えます。自律で進める場面と承認を求める場面のルールは組み込み済みで、カスタムルールを使えば特定の操作を「許可」「承認必須」「ブロック」に振り分けられます。組み込みの安全要件は、どんなルールを足しても常に適用されます。

自動レビューという仕組みもあります。アカウントに影響したり情報を共有したりしうる操作を、指示とルールと安全要件に照らして「そのまま進める」「承認が必要」「ユーザー自身で行う」のどれかに判定する仕組みです。パスワード変更のように特に慎重さが要る一部のタスクは、必ずユーザー自身が行います。

カスタムルールをどんな書式で書くのかは、公式発表ページでは確認できませんでした。開発の仕事に当てはめた振り分けを、私の見立てとして挙げます。

• 許可: リポジトリとissueの読み取り、作業用ブランチへのpush、テストの実行
• 承認必須: PRの作成、チーム外に届くSlackへの投稿
• ブロック: mainへのマージ、本番環境へのデプロイ、顧客へのメール送信

分け方の軸は、あとから取り消せるか、人に届くかの2つです。読み取りとブランチへのpushは、元に戻せて外にも出ません。PRの作成やチーム外のSlack投稿は人の目に触れるので承認を挟み、本番デプロイと顧客へのメールは、出た時点で影響が外に届くのでブロックです。

直接やり取りしていない時間の動きも決まっています。公式がプロアクティブリサーチと呼ぶもので、dotは読み取り専用に制限されたツールで接続済みのアプリを見て、役立ちそうなことを探します。この間はメッセージの送信も、アプリ内の変更も、ブラウザーやコンピューターの操作もできません。

今日から自動化を始められる人と、まだ始められない人

提供は9月29日から順次始まっています。公式の提供条件を、始められるかどうかで並べました。

対象は「対象地域の」ユーザーとされていて、発表ページの本文に国の一覧はありません。OpenAIのdotsのドキュメントには、Proは18歳以上でEEA・英国・スイス以外のユーザー向け、Business PremiumとEnterpriseは世界で順次展開中と書かれています。日本は除外に入っていません。ただし提供は順次なので、自分のアカウントにdotの作成画面が出ているかで確かめるのが確実です。

dotの作成はChatGPTのデスクトップアプリかPCのブラウザーから行い、初期設定を終えればモバイルアプリからも送信できます。dotの追加や作業量の拡大は今後の予定の段階なので、今は含まれている1つのdotで回すことになります。

仕事のコードを渡すなら、データの扱いの確認も欠かせません。Business、Enterprise、Eduのワークスペースの内容は既定でモデルの改善に使われず、個人向けプランではこの扱いを自分で設定できます。

最初の自動化は、上限が広がっている最初の1か月に

ProとBusiness Premiumにはより高度な作業向けの利用枠が含まれていて、提供開始後の最初の1か月はこの上限が拡大されます。公式の文面は「最初の1か月」とだけ書いていて、段階的な提供の中で各アカウントにdotが届いた日から数えるのかまでは読み取れません。

dotとの会話そのものは、ChatGPTの利用上限にカウントされません。ただし、dotにCodexやChatGPT Workでタスクを始めさせると、そのタスクは通常どおり利用上限に数えられます。

この1か月に自動化を試すなら、私の見立てでは、コードを変更させない仕事を1つだけ選ぶのが安全です。バグ報告のSlackチャンネル1つとリポジトリ1つだけをつなぎ、報告が来たら再現手順と原因の候補をスレッドに返してもらいます。pushとPRの作成はカスタムルールでブロックに置く想定で、dotの出口を調査メモに限ります。

これなら調査が外れても、読んだ人が遠回りするだけで済みます。コードにも顧客にも、何も届きません。

始める前に、1か月後に続けるか止めるかを決める基準を書き出しておきます。

• 調査メモのうち、原因の特定に役立った件数
• 原因の候補が外れて、読んだ人が遠回りした件数

役立った件数が外れた件数を上回れば、PRの作成を「承認必須」に移し、出口をPRまで広げます。下回れば止めて、渡した入力を見直します。あなたのチームで、バグ報告が一番たまっているSlackチャンネルはどこですか？ dotをつなぐ先は、そこで決まります。