dotの「完了しました」は仕事の完了？新規0本と公開済み記事から分かった4つの成功条件【2026年版】
ChatGPTのdotへ記事制作を任せた最初の連続試験で、処理そのものはかなり順調に進みました。
当時の会話記録では、約49分で3つのスレッドを処理し、既存のKnowledge記事を5本更新し、追加の本人操作は0回だったという報告が返っています。
数字だけ見れば成功です。
でも、僕がその試験で一番増やしたかったのは「新しいKnowledge記事」でした。結果は新規0本。
AI側では作業が終わっている。でも、僕が欲しかった成果には届いていない。dotを使って最初に強く感じたのは、この二つは別だということでした。
まず、何をやろうとしていたのか
僕はdotを使う前から、通常のChatGPTで「海辺の部屋」の記事制作をしていました。
過去の会話から材料を探し、記事へまとめ、Wixへ登録し、公開するところまで進めること自体は、新しい挑戦ではありませんでした。
dotで試したかったのは、その間にある長い仕事です。
複数の会話を採掘する。新規記事か既存更新かを判断する。次の素材へ進む。公開後の状態を確認する。僕がずっと会話へ張り付かなくても、その流れを続けられるかを試していました。
だから評価したい成果も、「何回ツールを動かしたか」ではなく、「新しい知識資産が増え、読める形で公開されたか」でした。
1つ目のずれ｜処理は成功した。でも新規記事は0本だった
最初の試験では、同じ分野の会話を複数処理すると、既存Knowledgeの更新へ寄りました。
既存記事を更新する判断そのものが間違いだったわけではありません。
重複記事を増やさず、既存記事を強くするのは通常なら正しい判断です。
でも今回の主目的は、3年間の会話から新しい知見を見つけ、新規Knowledgeを増やすことでした。
そこで僕は、「新規記事を増やしたいのがメイン業務」と目的を言い直しました。
ここでは「3スレッド処理」「5記事更新」「本人操作0回」という実行上の成功と、「新規Knowledgeを増やす」という目的達成が分かれています。
2つ目のずれ｜公開まで成功した。でも文章としては失敗だった
別の試験では、記事本文を作り、Wixへ保存し、公開確認まで進みました。
それでも僕が公開本文を読むと、「文章の構造が破綻してる」と感じる記事がありました。
これは最初の新規0本とは別の失敗です。
今度は記事そのものは新しく作られ、Wixにも公開されています。
つまり「記事を生成する」「CMSへ保存する」「公開する」という作業は通っています。
それでも、人間が読んで意味が分からないなら、BlogやKnowledgeとしての仕事は完成していません。
さらにもう一段あった｜読みやすくても、記事の答えが弱い
文章構造を直した後にも、別の指摘が残りました。
歴史的な経緯としては読みやすくなった。でも、「このKnowledgeは結局何を答えているのか」が弱い記事がありました。
ここでは、日本語として読めることと、Knowledgeとして一つの問いへ答えることが分かれています。
文章品質を一つの点数で考えると、この違いを見落とします。
自然な文章であること、事実が正しいこと、記事の主旨が通っていること、読者の問いへ答えていることは、別々に確認する必要がありました。
OpenAI自身も「run completed」と「結果達成」を分けている
この経験のあとでOpenAIの公式資料を読み直すと、近い区別が明示されていました。
Tasks and memoryには、タスクのrunが完了しても、それだけで依頼した結果が達成されたことや、期待した相手へ結果が届けられたことを確認したことにはならないため、出力やエラーを確認するよう説明されています。
これは「dotは失敗しやすい」という意味ではありません。
製品側でも、技術的な実行終了と、利用者が依頼した結果の達成は別の確認対象として扱われています。
僕は途中から、「完了」を4種類に分けて考えるようになった
今回の実験では、少なくとも4種類の完了を分けると整理しやすくなりました。
1. 実行完了
頼んだ処理やツール操作が最後まで走ったか。
2. 公開・受け渡し完了
成果物がWixへ保存され、公開され、利用者が実際に見られる状態になったか。
3. 品質合格
初めて読む人が理解できるか。事実を言い過ぎていないか。文章の主旨が崩れていないか。
4. 目的達成
そもそも欲しかった成果が増えたか。今回なら、新しいKnowledgeが増えたか、再利用できる知が残ったか。
一番下まで通って、初めて僕にとっての「仕事が終わった」になります。
自動化が速いほど、成功条件のずれも速く進む
ここで少し怖いのは、AIが遅い場合より、順調に動く場合です。
処理が遅ければ途中で人間が違和感に気づきやすい。
でもAIが自律的に複数スレッドを処理し、記事を次々保存できると、完成条件がずれたままでも作業は先へ進みます。
新規記事を増やしたいのに既存更新が続く。
初見で分かる記事が欲しいのに、読みにくい原稿がそのまま公開される。
自動化では、速さそのものより「何を成功と数えているか」を先に揃える必要があります。
その後、何を変えたのか
後半では、記事制作の工程を分けました。
素材を整理する。
その記事が答える問いを決める。
通常Chatで本文を書く。
初見の読者としてレビューする。
原資料と照合する。
修正後の全文をもう一度確認する。
Wixへ保存・公開し、公開後の本文も確認する。
当時の会話では、この手順で作った新しい5本について、僕自身が公開可能な品質だと評価しました。
完成条件を一文でまとめるより、「次へ進んでよい条件」を工程ごとに具体化したことで、完成判定が細かくなりました。
これは「人間が全部承認しよう」という話ではない
完了条件を増やすと、「それなら毎工程を人間が確認しないといけないのでは」と見えるかもしれません。
僕が目指したのは逆です。
人間にしか判断できない部分と、AI側で確認して次へ進める部分を分けることでした。
たとえばURLが公開されたか、画像が設定されたか、本文と公開版が一致するかは、条件が明確ならAI側で読み戻して確認できます。
一方、「この記事で本当に渡したい問いはこれで合っているか」という編集判断は、少なくとも今回の初期実験では何度か僕へ戻りました。
人間の確認回数を増やすのではなく、「確認しないと危ない場所」を特定して、それ以外を自動化する方が実務には合いました。
AIの「成功率」を見るときも、何を成功と数えたかを見る
この経験は、dotだけの話ではありません。
AIエージェントのベンチマークや導入事例で「90％成功」「100件処理」と書かれていたら、何を成功として数えているかを確認した方がよいと思います。
APIが最後まで走ったのか。
ファイルが生成されたのか。
ユーザーへ届いたのか。
内容が正しかったのか。
本来の業務目的を達成したのか。
同じ「成功」という言葉でも、どの段階を測った数字なのかで意味はかなり変わります。
結論：「完了しました」の次に、何が完了したかを見る
dotの最初の試験では、複数スレッドを処理し、既存記事を更新する作業は進みました。でも新規記事は0本でした。
別の試験では、記事は公開されました。でも僕が読んで、文章構造の問題を指摘しました。
さらに、文章が読めるようになっても、Knowledgeとして答えが弱いという問題が残りました。
この経験から僕が変えたのは、「完了したか」を聞くのではなく、「実行・公開・品質・目的のどこまで完了したか」を分けて確認することです。
OpenAIの公式資料も、runの完了だけでは依頼結果の達成や受け渡しを確認したことにはならないと説明しています。
AIが長い仕事を自律的に進めるほど、「何をもって仕事を終わりとするか」を先に決める価値は大きくなります。
「完了しました」と表示されたとき、次に見るのは、何が完了したのかです。
関連記事
テーマ別に読む
この記事を書いた人
マーケティングデザイナー／DXコンサルタント／音楽家。企業・自治体等60社以上のマーケティング・DX支援に携わり、生成AI・Web・EC・データ活用などを実務で検証・発信しています。
参考資料・参照元
可児波起・ChatGPT会話記録（2026年10月1〜2日、非公開一次記録）
コメント