フリマサイトの売却済み商品ページを、合計1,799件削除した。
dotに任せて、実際に完了した作業です。
前のモデルのエージェントモードでは長時間作業を的確にこなすことができなかったので半信半疑でプロンプトを打ち込み、とこについた。
朝起きると、驚愕。
正確にプロンプトを実行していました。
正直、驚きと同時に怖さも少し。
私が寝ている間に仕事をこなしていました。
一件ずつなら難しい操作ではない。
でも、同じ操作が何百回、何千回と続くと、それだけで手が止まる。やることはわかっているのに、後回しになる作業はあります。
今回は、そういう作業をdotに任せました。ほかにもブログ記事の公開や、既存ゲームの改善を依頼しています。
では、何ができたのか。以前のエージェントモードとは、何が違うのか。
できなかったことも含めて整理します。
1,799件。大事だったのは、削除数と残すものの確認
削除は、100件、500件、1,199件の3回に分けました。
なぜ分けたか。
まずは正常に動くかテストをしたかったからです。
変な動きをして、処理しきれないとか、多く消してしまうとかいう誤作動はないかを確かめたかったからです。
新しいものから古いものへ進め、最後の作業では古い50件を残す条件でした。
取り消せない操作なので、各回とも、実行前に対象と件数を確認して私が承認しています。
3回目は途中で一時的な502エラーが起きました。
310件までは完了が確認できたものの、311件目の結果が不明になった。
そこでいったん止まり、画面が戻ってから311件目の状態を確認。そのうえで再開しました。
最後は、残すと決めた古い50件が一致しているところまで照合しています。
ここでいう50件は、その作業が終わった時点の確認です。
件数だけ合っていても、残すべきものが消えていたら失敗です。
任せるときに必要なのは、「何をするか」に加えて、「何を残し、何をもって完了とするか」でした。
ブログ記事と、すでにあるゲームの改善も任せた
ブログでは2本の記事を、題材の調査、事実確認、本文とカバー画像の作成、WordPressへの公開まで進めました。
下書きに入れるだけという指示も正確に実行して最終承認手前でしっかり止めていました。
表示確認はデスクトップ表示とWordPressのモバイルプレビューです。
実機のスマートフォンで確認した、という話ではありません。
実際のアウトプットはこちらです。
プロフィール画像の縦横比も修正しました。
Astraで制作したゲーム、『恋愛以前。』では既存のゲームに案内リンクや、開始・再開の操作回数を数える計測の仕組みを追加しました。
また、操作回数がわかることと、遊んだ人数が正確にわかることは別です。
売上が増えたことを示す結果も、ここにはありません。
今回任せたのは、完成しているものの周辺に残る作業です。
記事を載せる。表示を確かめる。リンクを整える。動きを記録できるようにする。
こうした細かい作業まで進んで、ようやく使える状態になることがあります。
エージェントモードとの違いは、機能だけでは語れない
dotは、継続して仕事を任せることを前提にしたAIエージェントです。
2026年9月29日の公式発表では、会話の合間にも作業を進め、結果を持ち帰り、人の判断が必要なときには確認する設計が説明されています。公式発表
私が以前使ったモデルのAtras？のエージェントモードでは、同じ整理作業を完了できませんでした。
今回のdotでは、1,799件の削除を完了できた。この体験の差はあります。
ただ、その理由をdotの特定の仕組みだけで説明することはできません。
条件をそろえた比較実験ではなく、失敗と成功の原因を切り分けたわけでもないからです。
そもそも2025年7月に発表されたChatGPT agentにも、仮想コンピューターでのWeb操作、コード実行、資料作成、途中再開や定期実行の機能がありました。
「以前は返事だけ、dotになって初めて操作できる」という整理は正確ではありません。
なお、この発表ページは現在、古い情報としてChatGPT Workなどを案内しています。
現在のWorkと、私が以前使ったエージェントモードも分けて考える必要があります。
今回の使い方で注目したいのは、会話から離れている間も、決めた範囲の仕事が進み、確認できる結果として戻ってきたことです。
dotには専用のクラウド上のコンピューターとブラウザーがあります。
一方、自分のPCにあるファイルやアプリを使う作業には、アクセスの許可と、そのPCがオンラインであることが必要です。
どの作業もPCを閉じたままできる、と考えるのは早いのは確かです。コンピューターとアプリの接続について
動かないときは、動かない
1,799件のあと、別に26件の削除も依頼しました。
ただ、このときは商品一覧を読み込めず、dotが削除した件数は0件。
最後は私が手動で終えました。
前にできたから、続きから処理して、次も必ずできるわけではないことも確認できました。
サイトの状態やログイン、画面の読み込みによって、作業は止まります。
だから、完了報告では「試した」と「終わった」を分ける必要があります。
途中で止まったなら、どこまで確実で、何が未確認なのか。
そこがわからないと、人が引き継ぐときにまた調べ直すことになりますね。
最初に渡すのは、作業とその境界
試すなら、いきなり大量削除を任せるより、新しい記事の下書きなど、結果を確認してから使える作業が始めやすいと思います。
依頼するときは、次の5つを具体的にします。
- 対象：どのサイト、どの記事、どの範囲か
- ゴール：何件、どんな状態まで進めるか
- 残すもの：既存記事、画像、設定など、触らない範囲
- 止まる条件：エラー、対象の不一致、判断が必要な操作
- 確認方法：保存先、件数、表示、未完了部分の報告
たとえば、ブログならこんな依頼文です。
このメモをもとに、指定したWordPressで新しい記事の下書きを1件作ってください。既存記事、画像、テーマ設定は変更しないでください。公開はせず、私の確認を待ってください。確認できない事実は補わず、質問として残してください。ログインや保存でエラーが出たら止まり、保存できた範囲と未完了部分を報告してください。最後に下書きの編集URLと、表示を確認した結果を教えてください。
削除や公開のように影響が大きい操作は、対象と結果を理解したうえで、人が承認する。その判断まで曖昧に渡さないことが大事です。
任せたい作業は何か。残したいものは何か。どこで止まってほしいのか。
ここを言葉にすると、AIが進める部分と、自分が判断する部分が見えてきます。
まずは一つ、完了を自分で確かめられる作業から小さく任せてみる。
それが今回の実例から提案できる使い方です。
機能に関する公式情報は2026年10月3日時点で確認しています。この記事は個人の利用例であり、同じ結果を保証するものではありません。
感想を残すコメントを見る（0件）