24時間動くAIなのに、なぜ何度も「今、動いてる？」と聞いたのか｜ChatGPT dotで分かった状態管理【2026年版】
24時間動けるAIを試していたのに、僕は何度も「今、動いてる？」と聞いていました。
一見すると変です。人間が画面を見ていなくても作業を続けられるのがdotの価値なら、利用者が何度も進捗確認するのは、その価値を打ち消してしまいます。
でも実際に記事制作を任せてみると、僕が知りたかったのは「何％終わった？」だけではありませんでした。
今は処理中なのか。何かを待っているのか。僕の判断が必要なのか。AI側で再開できるのか。すでに失敗しているのか。
自律AIでは、「作業できること」と同じくらい、「現在の状態を正確に伝えられること」が重要だと気づきました。
そもそも、なぜ「24時間動くAI」を試したのか
僕がdotへ任せたのは、「海辺の部屋」のKnowledge制作でした。
通常のChatGPTでは、材料を探す、記事を書く、Wixへ登録する、公開を確認する、といった工程を会話しながら進めていました。
dotで試したかったのは、その工程の途中で僕が毎回「次へ進んで」と言わなくても、会話から離れている間に作業を継続できるかです。
OpenAIの公式説明でも、dotは会話の間も作業を進め、必要な判断があると利用者へ戻る常駐型エージェントとして説明されています。
つまり価値は「24時間計算し続ける」ことではなく、「人が見張っていない時間にも仕事を前へ進められる」ことです。
実験中、本文5本ができても公開は終わっていなかった
2026年10月2日の実験では、新規5本の本文について確認が終わった、という報告まで進みました。
でもその時点では、画像登録やWix上の公開工程が残っていました。
しばらくして僕が「公開した？」と聞くと、作業は停止中だと説明されました。
その後「続行する」と返答がありましたが、少し後には、実操作が再開したことをまだ確認できないという説明が続きました。
さらに画像アップロードで許可待ちになっている、という説明もありました。
僕から見ると、「続ける予定なのか」と「実際に次の操作が走っているのか」が同じ言葉の中に混ざっていました。
問題は「遅いこと」より、「何待ちなのか分からないこと」だった
外部サービスを操作する仕事では、待ち時間が発生すること自体は珍しくありません。
ログインが必要かもしれない。アプリ接続が切れているかもしれない。安全上の承認が必要かもしれない。本人しかできない操作かもしれない。単純に処理中かもしれません。
問題は、その違いが利用者から見えないときです。
原因によって、僕が取るべき行動はまったく違います。
本人操作が必要なら、すぐ僕へ戻してほしい。AI側で再試行できるなら、僕を呼ばずに続けてほしい。原因不明なら、その状態を伝えてほしい。
「止まった」という一語ではなく、「誰の何を待っているか」が分かることが重要でした。
OpenAIの公式資料でも、待ち状態は一種類ではない
OpenAIのControl your dotでは、Activityから進捗、ファイル、結果を確認できると説明されています。
また、dotが待つ理由として、利用者のdecision、app connection、sign-in、approvalなどが例示されています。
行動レビューでは、指示、権限、カスタムルール、安全要件をもとに、「そのまま進める」「承認が必要」「本人へ操作を渡す」を分けます。
さらにPauseは現在のメインタスクを止めますが、委任済みのすべてのタスクや将来のスケジュールまで止めるものではありません。
公式仕様を見ても、「動いている／止まっている」の二択ではなく、複数の状態を区別して扱う設計になっています。
「全部許可した」つもりでも、すべてが自動で通るとは限らない
実験中、僕はWix操作について広く許可する意図を伝えました。
それでも追加確認や待機が残る場面がありました。
この事実だけから、「dotは許可しても止まる仕様だ」とは言えません。今回の待機がWix側なのか、接続なのか、安全確認なのか、製品上の不具合なのかは特定できていないからです。
公式資料でも、カスタムルールは特定の操作への承認方法を指定できますが、アプリ自体へのアクセスを新たに与えたり、組み込みの安全要件や必須確認を無効にしたりするものではないと説明されています。
僕にとって重要だったのは、「権限を与えたか」と「今この操作を実行できる状態か」を分けることでした。
途中から欲しくなったのは、進捗率ではなく「状態ラベル」だった
僕が途中から何度も求めたのは、「動いているか、止まっているかを常に明示してほしい」ということでした。
今振り返ると、本当に欲しかったのは単純なON／OFF表示より、状態の分類です。
RUNNING：AI側で処理中
WAITING：外部の応答や時間を待っている
NEEDS DECISION：人間の判断が必要
NEEDS ACTION：ログインなど本人操作が必要
RECOVERING：AI側で再試行・復旧中
FAILED：自動では進められない
COMPLETED：決めた完了条件まで通った
これはOpenAIの正式なステータス名称をそのまま並べたものではなく、今回の実体験を僕なりに整理した状態モデルです。
利用者が自分から「今どうなってる？」と聞かなくても、どこにいるか分かる状態が理想でした。
状態説明には、最低4つあると分かりやすい
今後、自律AIへ長い仕事を任せるなら、僕は停止・待機の報告に最低4つ欲しいと思っています。
一つ目。現在の状態は何か。
二つ目。最後に成功した操作は何か。
三つ目。今は誰の何を待っているのか。
四つ目。次に誰が何をすれば再開するのか。
たとえば「画像アップロード待ち」だけではなく、「本文5本は完成。Wix画像アップロードで承認待ち。承認されればAI側で公開まで再開する」という形です。
これなら、利用者は進捗を監視するのではなく、必要なときだけ判断できます。
自律AIの価値は、「作業時間」より「注意を奪わない時間」にある
僕はdotを試したとき、単に夜中も働いてくれることだけを期待していたわけではありません。
AIが処理している間、自分は別のことをしたい。
だから本当に減らしたいのは、AIの処理時間ではなく、僕が画面へ張り付く時間です。
10分で終わるAIでも、その10分間ずっと「止まってない？」と確認するなら注意力を使います。
1時間かかっても、必要なときだけ正確に呼び戻してくれるなら、その1時間を別の仕事に使えます。
自律性は「何時間連続で動けるか」だけでなく、「その間、人間が見張らなくていいか」で評価した方が実務に近いと思います。
これはAIだけでなく、宅配やシステム運用と同じ
荷物の配送を考えると分かりやすいです。
「配送中です」とだけ表示されるより、「営業所を出た」「配達中」「不在で持ち戻り」「再配達待ち」と分かる方が、利用者は何をすればいいか判断できます。
システム運用でも、「動いている／落ちている」だけでなく、処理中、外部API待ち、リトライ中、手動対応待ちを分けます。
自律AIも、仕事を長く持つほど「状態を観測できること」が製品機能になります。
前の記事の「完了条件」と、今回の「現在状態」は別の問題
前の記事では、「実行完了」「公開完了」「品質合格」「目的達成」を分けました。
今回のテーマは、その手前です。
最終的に何を完了とするか決めても、途中で今どこにいるかが分からなければ、利用者は安心して離れられません。
完了条件はゴールの定義。状態管理は、ゴールまでの現在地です。
長い仕事を任せるには、両方が必要でした。
結論：24時間動くAIで重要なのは、「止まらないこと」だけではない
dotの実験中、本文が完成してもWix公開で止まり、僕は何度も「今、動いてる？」「公開した？」と確認しました。
これは、dotが24時間動けるという説明と矛盾する話ではありません。
自律的に長い仕事を持てるからこそ、処理中、外部待ち、承認待ち、本人操作待ち、復旧中、完了を区別して伝える必要が出てきます。
OpenAIの公式資料でも、Activityで作業を確認し、decision、app connection、sign-in、approvalなどの待ち状態に応じて利用者が対応する仕組みが説明されています。
僕が欲しかったのは、「絶対に止まらないAI」ではなく、「止まったら、自分から聞く前に、なぜ止まり、誰が何をすれば動くか分かるAI」でした。
自律AIの使いやすさを考えるとき、処理能力と同じくらい、状態を正確に伝える力を見るようになりました。
関連記事
テーマ別に読む
この記事を書いた人
マーケティングデザイナー／DXコンサルタント／音楽家。企業・自治体等60社以上のマーケティング・DX支援に携わり、生成AI・Web・EC・データ活用などを実務で検証・発信しています。
参考資料・参照元
可児波起・ChatGPT会話記録（2026年10月1〜2日、非公開一次記録）
コメント