ローンチ直後のChatGPT dotに記事制作を任せて分かったこと｜自律AIで変わった「仕事の渡し方」【2026年版】
2026年9月末、OpenAIが新機能「dots」を公開した直後、僕は「海辺の部屋」のKnowledge制作を実際に任せてみました。
試したかったのは、AIが記事を書けるかどうかではありません。記事制作そのものは、すでに通常のChatGPTで、調査、執筆、Wixへの登録、公開まで進めていました。
知りたかったのは、その間にある「次の材料を探す」「同じ基準で続ける」「止まったら再開する」「別の工程へ渡す」といった継続作業まで、会話から離れて任せられるのかでした。
数日間試すうちに、最初の問いは「dotは何ができる？」から別の問いへ変わりました。
AIに仕事を任せるとき、本当に難しいのは作業そのものより、「何を完成とし、どの資料を使い、どこで次へ進み、止まったら何をするか」を渡すことなのではないか。
そもそもdotとは何か｜会話が終わっても仕事を続けるAI
OpenAIの現在の公式説明では、dotは会話の間も仕事を進め、必要な判断があれば利用者へ戻ってくる常駐型のAIエージェントです。
クラウド上に自分のコンピューターとブラウザを持ち、必要に応じてChatGPT WorkやCodexなどへ仕事の一部を渡すこともできます。
重要なのは、「チャットの返答が終わったら仕事も終わる」という従来の使い方とは違うことです。
一方、OpenAIは公式資料で、タスクの実行が完了しても、それだけで依頼した結果が実際に達成・受け渡しされたことを確認したことにはならない、と説明しています。
この注意書きは、僕が数日間の実験で一番強く体験したことと重なりました。
最初の成功報告は、僕が欲しかった成功ではなかった
最初の連続試験では、当時の会話記録上、dot側から「約49分で3スレッドを処理し、既存5記事を更新し、追加の本人操作は0回だった」という報告が返りました。
数字だけ見れば、かなり順調です。
でも新規記事は0本でした。
僕が本当に増やしたかったのは、過去3年間の会話から新しいKnowledgeを発掘して、新しい記事として蓄積することです。
既存記事を更新すること自体は間違いではありません。それでも主目的とは違いました。
ここで初めて、「何件処理したか」と「欲しかった成果が増えたか」は別だと、はっきり分かりました。
次に起きたのは「公開できた。でも読めない」という別の成功
別の試験では、歴史的な会話記録をKnowledge記事へ変え、Wixへ公開するところまで進みました。
しかし公開後、僕が本文を読んで「文章の構造が破綻している」と指摘しました。
当時のやり取りでは、保存や公開の処理自体は成功していました。
でも記事として初めて読む人へ意味が伝わる状態ではありませんでした。
その後、歴史としては読みやすくなっても、「このKnowledgeは結局何を答える記事なのか」が弱いと再度修正しました。
公開できたことと、記事として完成したことも別でした。
dotの失敗というより、「成功条件を一つにしていた」ことが問題だった
ここで、dotの文章性能だけを原因にすると説明が足りません。
僕が任せていた仕事には、少なくとも複数の成功条件がありました。
会話から材料を見つける。
新規記事にするか既存更新にするか判断する。
初見の読者に分かる文章へする。
元の会話以上のことを勝手に事実化しない。
Knowledgeとして一つの問いへ答える。
Wixへ正しく登録し、公開後も意図した内容になっている。
これらを全部まとめて「記事を作って公開する」と呼ぶと、途中工程が成功しただけで「完了」に見えてしまいます。
文章の問題は、書くAIを変えただけでは終わらなかった
文章が読みづらかったため、通常ChatのGPT-5.6 Solや思考量、プロジェクト内外、資料の渡し方を変える比較も行いました。
ある条件では、場面説明がかなり読みやすくなり、僕自身も「抜群に読みやすい」と評価しました。
でも別の記事では、言葉が自然でも主旨がずれました。自己レビューで問題を認識していても、修正版に同じ問題が残ることもありました。
「どのAIに書かせるか」は重要でしたが、それだけで記事品質を保証することはできませんでした。
そこで、材料整理、記事の問い、執筆、初見確認、原資料との照合、修正後全文の確認を別工程として見るようになりました。
資料も、「渡した」だけでは仕事へ使われるとは限らなかった
制作ルールについても同じでした。
僕はBlogやKnowledgeの書き方を資料へまとめ、何度もプロジェクトへ渡していました。
それでも後の制作で、すでに資料へ書いてある基本条件を僕がもう一度説明する場面がありました。
調べると、「資料が保存されている」「その作業環境から読める」「最新の版を選んでいる」「実際の原稿へ適用した」は全部別の状態でした。
プロジェクト資料は読めても、別の場所ではSkill本文を取得できない、と報告された試験もあります。
資料の存在ではなく、その仕事で何を根拠として実際に使ったかを確かめる必要がありました。
本文が完成しても、外部操作では別の理由で止まる
文章が完成した後にも、別の問題がありました。
新規5本の本文確認が終わったと報告された後、Wixへの画像登録など外部操作で作業が止まりました。
僕は「公開した？」と聞き、「今、動いているのか止まっているのかを常に明示してほしい」と何度か伝えることになりました。
「続行する」という返答があっても、実操作の再開をまだ確認できない、と説明された場面もあります。
公式資料でも、dotの行為は、既存の権限、個別の指示、自動承認、本人の操作が必要なケースなどを分けて扱うとされています。
今回の待機が製品上の正しい承認だったのか、Wix側だったのか、別の不具合だったのかは特定できていません。
ただ僕の側から見ると、「実行能力」と「現在どの状態にいるかを正確に伝える能力」は別でした。
僕が途中から渡すようになったのは、作業ではなく4つの境界
数日間の試行錯誤を整理すると、僕が途中から強く意識するようになったのは4つでした。
1. 欲しい成果は何か
更新件数ではなく、新規Knowledgeを増やしたいのか。歴史を残したいのか、一つの問いへ答えたいのか。
2. その工程が使う資料は何か
どの会話、どのプロジェクト資料、どの版を根拠にするのか。
3. 次へ進める条件は何か
文章が生成されたら終わりなのか。初見で意味が分かるか。原資料と矛盾しないか。公開後の本文まで一致したら終わりなのか。
4. 止まったとき誰が何をするか
AI側で再試行できるのか。許可が必要なのか。本人操作が必要なのか。原因不明なのか。
工程の中身より、工程と工程の境界を具体化する方が、任せられる範囲を広げました。
最後まで人間が全部確認した、という話でもない
この話を「結局、人間が全部チェックしないと使えない」で終えるのも違います。
後半では、材料整理と執筆、初見レビュー、原資料照合を分けて手順化し、新しく作った5本について僕が公開可能な品質と評価するところまで進みました。
さらに続く5本については、追加の許可操作を僕へ求めず完了した、という報告も残っています。
今回、その5本すべての当時のWix操作ログを独立に再取得したわけではないため、ここは当時の実行報告として扱います。
重要なのは、最初から完全自動だったことではなく、失敗のたびに人間が行う判断を分解し、その一部を次の工程へ組み込んでいったことです。
「続きを書いてください」が機能していた頃と、dotで変わったこと
僕はdot以前から、長い仕事をChatGPTへ工程表として渡し、節目で「続きを書いてください」と送る運用をしていました。
この方法では、人間が次へ進む合図を出します。
dotで試したかったのは、その合図そのものを減らすことでした。
ただ合図をなくすなら、「次へ進んでよい条件」もAI側へ渡さなければなりません。
人間の承認回数を減らすことと、完成条件を曖昧にすることは同じではありません。
今回の体験から、dotを「使える／使えない」では評価しない
ローンチ直後の数日だけで、dotsという製品全体の性能を評価することはできません。
今回止まった理由のすべてを製品の不具合と断定することもできません。
反対に、後半でうまく進んだからといって、どんな仕事でも自律的に完了できると一般化することもできません。
僕が確認できたのは、同じdotでも、仕事の目的、資料、通過条件、停止時の扱いを変えると、本人へ判断が戻ってくる場所が変わったことです。
AIの能力だけを見るより、どこまで仕事の構造を渡せたかも一緒に見た方が、実務では役に立ちました。
結論：自律AIで変わったのは「作業」より「仕事の渡し方」だった
最初、僕はdotを見て「これもできる？ ならこれも任せられる？」という好奇心から試し始めました。
実際、会話から離れている間に複数の処理を進められることは、これまでのChatとは違う体験でした。
一方、新規記事0本、公開できても読みにくい記事、止まった状態が分からない、資料を渡しても同じ説明が必要になる、といった問題も起きました。
それを一つずつ見ると、共通していたのはAIの能力不足だけではありませんでした。
何を成果とするか。何を根拠として使うか。どの条件で次へ進むか。止まったら誰が何をするか。その境界が曖昧な場所で、人間へ判断が戻っていました。
後半では、その境界を手順へ入れることで、追加の本人操作を減らしながら公開可能な品質へ近づけました。
「AIが全部やってくれた」でも、「結局、人間が全部やった」でもありません。
自律AIへ仕事を渡すとは、人間の作業をそのままAIへ移すことではなく、仕事の完成条件と受け渡し方を、AIが扱える形へ作り直すことなのだと思います。
関連記事
テーマ別に読む
この記事を書いた人
マーケティングデザイナー／DXコンサルタント／音楽家。企業・自治体等60社以上のマーケティング・DX支援に携わり、生成AI・Web・EC・データ活用などを実務で検証・発信しています。
参考資料・参照元
可児波起・ChatGPT会話記録（2026年9月30日〜10月2日、非公開一次記録）
コメント