DotsはChatGPT agentモードの一般的な使い方と、具体的にどのステップで異なるのか？
通常のagentモードは今も「ユーザーが開始し、エージェントが実行し、結果を報告し、次の指示を待つ」という同期ループである。複数ステップの計画が途中にあっても、ユーザーはループの開始点と終了点のままだ。Dotsは起動後バックグラウンドで継続的に動作するよう設計されており、公式には「最小限の監督」が必要とされる——つまり次の指示を待って続けるのではなく、完了するか承認が必要なポイントに達するまで、自ら目標に向かって進み続ける。
この違いは微妙に聞こえるが、「誰が先に問題に気づくか」を決定する。対話型エージェントが間違えば通常次のやり取りで気づく。常時稼働型エージェントが間違えれば、自発的な報告か、何らかの外部信号を待つ必要がある。
なぜDotsは特にMicrosoft Agent 365のセキュリティ管理と統合するのか、自前のガバナンス機構では不十分なのか？
モデル自体の判断力だけでエージェントの間違いを防ぐことには根本的な限界がある——モデルは何らかの状況の組み合わせで常に誤判断する可能性があり、これは訓練だけで完全に排除できるリスクではない。企業の現場では、バックグラウンドで継続的に稼働し、コミュニケーションツールと連携し、複数ステップの自律性を持つエージェントが誤判断を下し、それを外部機構が捕捉できなければ、対話型エージェントよりはるかに大きな影響範囲を生む可能性がある。
Microsoft Agent 365が提供するID管理、アクセス範囲の制御、監査記録は、従来のITガバナンス層で既に検証済みの機構だ。Dotsが新たに発明するのではなく統合を選んだことは、ある意味でOpenAI自身も「常時稼働型エージェントのリスク管理はモデル層だけに頼れない」と判断したことを示している。
自分で常時稼働型エージェントを構築する場合、記事で触れられた「終了条件」は具体的にどう設計すべきか？
重要なのは「成功時に何をするか」だけを定義するのではなく、「失敗時に停止すべき信号」も同時に明確に定義することだ。よくある落とし穴は、エージェントに目標だけを伝え（例えば「顧客報告を継続的に監視しバグを修正する」）、その目標自体がすでに古くなっているか誤解されている可能性がある状況を定義しないことだ——結果としてエージェントは、自分の視点からはまだタスクが完了していないため、間違った方向に向けてバックグラウンドで無期限に努力を続けることになる。
実務上、終了条件は少なくとも3種類を含むべきだ：明確な完了基準（定量化・検証可能）、タイムアウト機構（想定時間を超えたら継続せず一時停止して報告する）、環境変化によって引き起こされる再確認（目標が依存する前提条件が変わった場合、元の計画通り実行するのではなく、停止して人間に再確認させる）。
現在チームは対話型エージェントを使っているが、これら3つのブレーキ機構を本気で検討すべきなのはいつか？
Dotsのような常時稼働型エージェント製品を導入する時を待つ必要はない。エージェントが「人間が一つずつ承認しなくても複数ステップを連続して実行できる」能力を持ち始めた瞬間から、すでに検討が必要な範囲に入っている——表面上は依然として1つの指示で起動するものであっても、起動後に十数ステップを自律的に実行し、複数のツールを呼び出してから結果を報告するようになれば、人間の介入のタイミングはすでに遅れてしまっている。
実用的な判断基準はこうだ：エージェントの1回の実行時間が長すぎてずっと見ていられない場合、または知らないうちに書き込み系のツール（メール送信、注文、ファイル変更）を呼び出す場合、この3つの機構はすでに必須項目であり、24時間常時稼働になってから補うものではない。
2026年9月29日のOpenAI DevDayで、OpenAIは「Dots」という新製品を発表した。GPT-6 Astraに駆動される個人用エージェントで、公式には「always-on」(常時稼働)と説明されている。従来の「文字を打って質問し、1回答えが返ってくる」という対話モデルとは異なり、Dotsは起動後バックグラウンドで継続的に動作し、ユーザーが設定した目標に向かって、タスクを完了するか人間の承認が必要なポイントに到達するまで進み続けるよう設計されている——対話ウィンドウを見張る必要はない。これはエージェント能力の自然な進化に聞こえるが、開発者にとってこの変化が伴うのは「モデルが強くなった」以上のこと——システム全体の責任分配の仕組みが変わるということだ。
従来のエージェントのワークフローは、本質的に同期ループである：ユーザーが指示を出し、エージェントが実行して結果を報告し、次の指示を待つ。複数ステップの計画能力を持つエージェントでも、ユーザーはループの開始点と終了点の両方であり続け、何か問題が起きれば通常次のやり取りで発覚する。Dotsが破るのはまさにこの前提だ。OpenAIは「最小限の監督でユーザー定義の目標にバックグラウンドで継続的に取り組む」能力を持つと説明し、例としてソフトウェア開発者が専用のdotを配置して顧客からの報告を継続的に監視しバグを修正する、あるいは科学者がdotに分析を再実行させ実験データの異常を調査させるといった使用例を挙げている。これらの場面に共通するのは、あなたが見ていない間もエージェントが判断を続け、ツールを呼び出し、何かを変更し続けているということだ。
注目すべき技術的シグナルがある。DotsはMicrosoft Agent 365のセキュリティ管理と統合することを選択し、Slack、Teamsなどの組織向けコミュニケーションプラットフォームをサポートする。この選択自体が、OpenAIの「常時稼働エージェント」のリスクに対する判断を示している——企業の現場では、バックグラウンドで継続的に稼働し、コミュニケーションツールと連携し、複数ステップの自律性を持つエージェントは、モデル自体の判断力だけでは不十分だ。外部のID管理、アクセス範囲の制御、監査記録といった従来のITガバナンスツールで補う必要がある。これはエージェントセキュリティ全体の潮流とも一致する——モデルが毎回正しい判断を下すことに賭けるのではなく、「エージェントが間違える」という完全には排除できないリスクを、アーキテクチャ設計によってその影響範囲を限定するという方向性だ。
自社システムに常時稼働型エージェントを導入する予定がある場合（DotsのAPI経由でも、自社構築の類似アーキテクチャでも）、対話型エージェントの時代には一時的に無視できたが、常時稼働モードでは必須となる3つの設計要素がある。
第一に、明確な終了条件。対話型エージェントの終了条件は単純だ——ユーザーが新しい指示を送らなくなればタスクは終わる。常時稼働型エージェントは起動時に「何が完了とみなされるか」「何が失敗で停止すべきか」を明確に定義しておかなければならない。そうでなければ、すでに古くなっているか誤解している可能性のある目標を、バックグラウンドで無期限に試み続けることになる。
第二に、事後の対処ではなく、いつでも介入できる中断機構。エージェントがバックグラウンドで動いているとき、人間が問題に気づくタイミングは本質的に遅れる——一歩一歩の実行を見ているわけではなく、報告が来るのを待つか、何らかの外部信号が問題を知らせてくれるのを待つことになる。これはシステム設計上、エージェントが現在「何を考えているか」を理解する必要なく即座に停止できる中断点が必要であることを意味する——一巡の処理が終わるまで介入できないのでは不十分だ。
第三に、変更の追跡可能性を対話型エージェントよりはるかに完全にすること。人間がすべての判断を目撃していない場合、事後に「エージェントが実際に何をし、なぜそうしたのか」を再構築することが極めて重要になる——これがDotsがチャットログウィンドウだけに頼らず、企業級のセキュリティ管理と監査機能を統合することを選んだ理由だろう。開発者にとって、常時稼働型エージェントのログ記録の粒度は「何が入力され何が出力されたか」だけでは不十分で、途中でどのツールを呼び出したか、どの権限を取得したか、どの時点でどの判断を下したかも含める必要がある。
チームが常時稼働型エージェントアーキテクチャの採用や構築を計画している場合、本当に予算を割くべきは「エージェントにもっと多くのことをさせる」機能開発ではなく、上記3つのブレーキ機構である。これらは最初のプロダクトデモにはほとんど含まれないが、常時稼働型エージェントがローンチ後に初めて間違いを起こしたとき、それが「追跡可能で停止可能な小さな問題」になるか「誰にも気づかれずに拡大し続ける大きな問題」になるかを決める分水嶺だ。always-onエージェント製品やフレームワークを評価する際は、何ができるかを問う前に、終了条件、中断機構、監査記録がどこまで整備されているかを先に確認するべきだ。