常時稼働のAIは、止まっても知らせない——56日で11日動かず、「成功」表示の2回は7秒と8秒で終わっていた

OpenAIが2026年9月29日、24時間働けると説明するAI「dots」を発表しました。人が話しかけなくても、決めた役割で自分から動く「常時稼働のAI」を会社に置く話が、現実になります。先に結論を書くと、常時稼働のAIは、止まったことを自分では知らせません。止まった仕事は「止まりました」と言えないからです。自社の定時タスク1本の実行履歴で、直近50回を数えたところ、定時に始まったのは39回でした。別に、56日のうち開始が1回もない日が11日あり、状態の欄が「成功」の2回は、約7秒と約8秒で終わっていました。

常時稼働のAIとは——OpenAIが9月29日に出した「dots」

常時稼働のAIとは、人が話しかけていない間も、決めた役割や予定に沿って自分で作業を始めるAIです。OpenAIは9月29日、開発者向けイベントのDevDay 2026でdotsを発表し、「常時稼働のエージェント」と説明しています。

dotsが何をするか

OpenAIの説明では、dotsはGPT-6 Astraを搭載し、専用のクラウドコンピューターを持ち、フィードバックから学びながら24時間働けます。プラグイン経由で4,000以上のアプリに接続でき、連絡の経路は、ChatGPT、テキストメッセージ、Slack、Teamsと音声通話です。dotの側からも、進捗、質問、判断が必要な事柄が届きます。人とやり取りしていない間に役立つことを探すプロアクティブリサーチは、読み取り専用に制限されたツールを使うので、メッセージの送信はできません。

提供は、対象地域のProとBusiness Premiumのユーザー向けに順次で、最初のdotは追加料金がかかりません。Enterpriseは、管理者が有効にするとベータ版を試せます。対象地域は、公式ページで確かめてください。

承認の設計と、組織向けの始まり方

dotsには、自律的に動く場合と承認を求める場合を定めたルールが組み込まれています。カスタムルールで操作ごとに選べるのは、許可、承認必須、ブロックの3つです。紹介ページには、「dot は間違えることもあるため、重要な影響を伴う作業は必ず確認してください。」とあります。

組織の特定の業務を担う「専門 dot」は、企業向けの限定プレビューです。OpenAIのエンジニアリングチームが各組織と直接協力して、dotの担当業務、使えるツール、人が作業を確認・承認する方法を定める形で始まります。

「常時稼働」の中身は3社で違う——動く場所と、動かなかったときの扱い

動く場所が自分のPCかクラウドかで、止まり方は変わります。Claude Codeのデスクトップアプリの定時タスクは、決めた時刻になるとAIが新しい作業を自動で始める設定で、利用者のPCの上で動きます。動くのは、アプリが開いていてPCが起きている間だけです。ノートPCのふたを閉じるとスリープするので、スリープしたまま予定時刻を過ぎた回は、スキップされます。スキップとは、その回を実行せずに飛ばすことです。

もう1つのルーティンは、Anthropicが管理するクラウド上で動き、ノートPCを閉じても動き続けます。一部の操作を除いて、承認のために止まりません。GoogleのGemini Sparkは、Geminiアプリの中で動く個人向けのエージェントです。

dotsは公開の翌日で、私たちが読んだのは紹介ページまでです。動かなかったときの扱いは、次の表に入れていません。

Gemini Sparkのヘルプは、電源が切れたときの書き方が2通りある

デバイスの電源が切れているときの扱いは、2つのページで食い違って読めます。スケジュールの作成と管理のページの、よくある質問のタイムゾーンの項は、次のとおりです。「Gemini Spark は、スマートフォンやパソコンではなくクラウドで動作します。つまり、デバイスの電源がオフになっていても動作し続けます。」

一方、タスクとワークフローを管理するページの、Gemini Sparkをオフにする項の重要事項は、次のとおりです。「Spark がオフになっている場合や、デバイスがオフになっている場合は、スケジュールは実行されません。」

どちらがいまの挙動なのかは、2つの文が同じ状況を指しているのかも含めて、私たちは確かめていません。

どの仕組みが自社の仕事に合うかを整理したい方は、FDE型AI導入支援（無料相談・無料AI診断）からご相談ください。

自社の実行記録50回を数えた——定時に始まったのは39回、開始のない日が11日

ここからは自社の記録です。対象は、毎日16時40分台に始まる設定の定時タスク1本で、記事を1本書いて公開する仕事を、Claudeのデスクトップアプリで動かしています。期間は2026年8月5日から9月29日の56日間で、履歴は全62回のうち取得できた直近50回、時刻は日本時間です。状態の欄、つまり履歴に出る「成功」「失敗」「実行中」の表示は、成功48回、失敗1回、実行中1回で、実行中の1回は、この記事を書いている回です。

定時に始まった回

定時の16時41分から16時51分に始まったのは、50回のうち39回でした。残る11回は、定時から外れた時刻に始まっています。例は、9月1日の6時55分、9月9日の23時53分、9月25日の22時15分です。文書は、各タスクが予定時刻から数分の遅れで始まると書いていて、この3回は数分の範囲に収まりません。午前9時の予定が午後11時に動くことがあるという文書の例とは並びが合いますが、11回それぞれの理由は、切り分けていません。

開始のなかった日

56日のうち、開始が1回もない日が11日ありました。9月19日から21日は、3日続けて開始がありません。文書によれば、アプリの起動時やPCの復帰時には、過去7日間の取りこぼしのうち直近の1回だけを追いかけ実行し、古い分は捨てます。追いかけ実行とは、取りこぼした回を、あとから1回だけ実行することです。開始のない日があることは、この説明と並びが合います。ただし、11日それぞれがPCを閉じていた日だったのかは、確かめていません。

同じ56日を、開始があったかどうかと、その日の日付で夕方の記事が出たかどうかで分けたのが、次の図です。開始があった日は45日、記事が出た日は33日でした。

開始があったのに記事が出なかった15日には、遅れて始まった回が翌日の日付で記事を出した日、別の経路ですでに記事が出ていて確認だけに切り替えた日、この記事を書いている回が始まった9月29日が含まれます。15日すべてが失敗だったとは言えず、1日ずつの理由は切り分けていません。

前の回が終わった直後に始まる回

前の回の最後の動きの時刻から、4秒後、11秒後、23秒後に次の回が始まった例が、3回あります。始まったのは、9月9日の23時53分、9月22日の8時11分、9月27日の17時19分です。最後の動きの時刻とは、その回の会話で最後に何かが記録された時刻のことで、作業時間ではありません。人があとからその会話を開いて続きを書いた時刻も含みます。文書がスキップの理由に挙げる、前の回がまだ実行中だった、とは並びが合います。ただし、各回の理由は1件ずつ確かめていないので、原因とは断定しません。

「成功」の表示は、仕事が終わったという意味ではない——48回のうち2回は約7秒と約8秒

Anthropicは、クラウド側のルーティンの文書で、実行一覧の緑の表示は、会話が始まり、基盤側のエラーなしに終了したことを意味し、指示した仕事が成功したことは意味しない、と注記しています。私たちが動かしているのはデスクトップの定時タスクで、この注記があるのはクラウド側の文書です。対象は違いますが、同じことが手元の記録でも起きていました。

成功と表示された48回のうち2回は、9月10日の16時43分と9月11日の16時42分に始まった回で、開始から最後の動きまでが、約8秒と約7秒でした。会話の記録は2件だけで、中身は指示文と、コマンドを1回呼んだことです。どちらの回からも記事は出ず、状態の欄は「成功」のままです。止まった理由は、記録からは分かりません。失敗と表示された1回は、9月7日の16時42分に始まり、執筆を別のAIに任せるところまで進んだあと、AIのプロセスが異常終了した記録が残っていて、理由が読めました。任せた仕事の完了を人の側で決める設計は、別の記事で書いています。

同じ型は、別の定時ジョブでも起きていました。定時ジョブとは、決めた時刻に自動で動く仕事のことです。自社では、ジョブの自己申告とは別に、外から結果を確かめる監視を、8月13日から1日2回回しています。週1回の計測ジョブは、8月20日、8月27日、9月3日の3週続けて、最後まで動いたのに、計測データが1件も取れていませんでした。原因は、アクセス解析への認証の期限切れです。認証の期限切れとは、AIが外部のサービスに入る許可証の有効期限が切れることです。動いているのに何も測れていない状態を見る検査を8月21日に足すと、8月27日に初めて鳴り、8月29日から9月2日の5日間に同じ警告が10回出ました。週1回のジョブなので、中身は同じ状態の数え直しでした。

止まった知らせは、止まったジョブの外に置く

監視が警告を出しても、その警告が読まれなければ、止まっていることは誰にも伝わりません。8月30日から9月2日に起きたことが、その例です。

壊れていたのは、検知ではなく、知らせの出口でした。検知は毎回できていたのに、出口が止まったジョブ自身の手元にありました。

別の例もあります。社内の記録を巡回するジョブは、8月17日、20日、24日、25日の4回「失敗」と記録されましたが、巡回自体は4回とも成功し、落ちたのは、結果を外部へ同期する最後の1手でした。通信の一時的な失敗です。「失敗」の表示も、開いて読むまで中身は分かりません。検査の側が古くなる例もあります。朝の定時の仕事を9月1日にやめると決めたあとも、監視は「今日の朝の記事が無い」と鳴らし続けました。検査の側が、やめるという決定を知らなかったからです。

表示や履歴で分かる止まり方は、図の上の段です。確かめる仕組みを足す先は、下の段の、表示では分からない2つです。最後まで動いたのに何も測れていなかった計測ジョブも、左下に入ります。

常時稼働のAIを入れる前に決める5つ

私たちの立場は、毎朝AIが動いたかを確かめる係を、社員に足さないことです。係を足すと、その人の仕事と責任が増えるだけで、続かないと考えています。確かめる仕事も仕組みに持たせ、止まった知らせは、責任を持つ人が毎日見る場所に届けます。人に残すのは、確かめる作業ではなく、知らせを受け取って判断することです。

承認ボタンに頼らない設計と、つないでいい範囲の決め方は、それぞれ別の記事で整理しています。止まる原因は、予定や承認だけではありません。AIのモデルにも終了日があり、3社の予告の違いは、別の記事で突き合わせました。

よくある失敗・NGパターン4つ

• PCを閉じて帰る運用のまま、ローカルの定時タスクに毎日の仕事を任せる。自社の記録では、開始のない日が56日のうち11日ありました。
• 「成功」の表示を見て終わりにする。成功の2回は、開始から約8秒と約7秒で最後の動きが止まり、記事は出ていませんでした。
• 警告を、そのAIが片づける場所に置く。警告8件が積まれ、未整理のファイルは26件に増えました。
• 鳴りっぱなしの警告を放置する。決めたことを、検査に伝えない。同じ警告が5日間で10回出ました。仕事をやめたあとも、監視は鳴り続けました。

自社の常時稼働のAIが、止まっても気づける形になっているか確認したい方は、無料相談でも確認可能です。

よくある質問

まとめ

常時稼働のAIは、動く場所で止まり方が変わります。自社の直近50回の履歴では、定時に始まったのは39回で、56日のうち開始のない日が11日ありました。「成功」の表示は、仕事が終わった印とは限らず、約7秒と約8秒で終わった回もありました。止まったことは、止まったAIの外から確かめ、その知らせは、責任を持つ人が毎日見る場所に置きます。確かめる仕事も、仕組みに持たせてください。