
OpenAI dotsが示す常駐AIエージェントの実務|自律実行と承認設計をどう両立するか
目次
1. AIエージェントは「頼まれて動く」から「先回りして働く」へ移る
生成AIを業務に入れるとき、これまでは「人がAIに依頼する」体験が中心でした。資料を要約してほしい、メールを下書きしてほしい、コードを直してほしい。依頼すれば速く返ってくる一方で、仕事の開始点は常に人間側にあります。忙しい人ほど、AIに頼むための整理や指示出しが後回しになり、結局いつものやり方に戻ってしまうことも少なくありません。
OpenAIが2026年9月29日に発表したdotsは、この前提を一段進める発表です。OpenAIの公式発表によると、dotsはGPT-6 Astraを基盤にした常駐型のAIエージェントで、自分専用のクラウドコンピューター、ブラウザー、接続済みアプリを使いながら、ユーザーの目標に向けて継続的に働きます。ChatGPT、Slack、Teamsから連絡でき、必要に応じて進捗や確認事項をユーザーへ返す設計です。
このニュースが企業にとって重要なのは、AIの役割が「会話の相手」から「仕事を預かる実行主体」へ近づくからです。便利さは大きい一方で、常駐エージェントは情報を読み、判断し、作業を進め、場合によっては社内外のツールへ触れます。導入の成否は、どれだけ賢いかだけでは決まりません。どこまで任せ、どこで止め、何を承認し、どのログで説明できるようにするかが問われます。
常駐AIエージェントは、ユーザーの目標、クラウド上の実行環境、アプリ権限、承認判断、監査ログを一体で設計する必要があります。
2. OpenAI dotsで何が発表されたのか
OpenAIの公式発表では、dotsは「自分の代わりに継続して働く」エージェントとして説明されています。各dotはクラウドコンピューターとブラウザーを持ち、ユーザーが接続したアプリを使って作業できます。ユーザーはdotのコンピューターを開いて作業状況を確認でき、必要であれば自分の端末へ接続する許可も与えられます。
使い方の例も具体的です。開発者向けには、顧客フィードバックを見て改善点を整理し、修正を実装し、テストし、変更内容を動画付きのPull Requestとして用意する例が示されています。プロダクトローンチでは、要件変更に応じて資料やメッセージを更新する。研究者向けには、新しいデータが届いたら分析を走らせ、図表を更新し、論文の説明に反映すべき点を示す。営業では、顧客要件や過去の商談履歴を見て、検証すべき論点や提案書を更新する。コンテンツ制作では、インタビューからクリップ候補や投稿案を作る、といった用途が挙げられています。
提供面では、まずChatGPTのProとBusiness Premiumの対象ユーザーへ展開され、Enterprise、Edu、Healthcareは管理者が有効化したベータとして試せるとされています。最初のdotはProまたはBusiness Premiumに含まれ、会話はChatGPTの通常利用上限に数えられません。一方で、dotがCodexやChatGPT Workのタスクを開始・管理する場合は、それぞれの利用上限に従います。将来的には複数のdotや、処理速度・作業量を拡張する形も示唆されています。
企業向けに特に重要なのは、specialist dotsのプレビューです。OpenAIは、組織が専用の責任範囲を持つdotを設け、独自のID、資格情報、システム連携を持たせる構想を示しています。調達、請求処理、メールマーケティング、顧客サポート、商業契約などで社内テストを進めていると説明されており、Microsoft Agent 365の企業向けガバナンスやセキュリティ管理との統合も計画されています。
3. 実務で重要なのはクラウドコンピューターより権限設計
dotsの目立つ特徴は、クラウド上に自分のコンピューターを持ち、ブラウザーや接続済みアプリを使えることです。しかし、企業導入で本当に重要なのは「何ができるか」ではなく「何をしてよいか」です。クラウドコンピューターを持つAIは、チャット欄の中だけで完結するAIよりも業務システムに近い場所で動きます。つまり、従来のSaaSアカウント、RPA、業務アプリ、開発者権限と同じように、権限設計の対象として扱う必要があります。
OpenAIの公式発表では、dotsはユーザーが接続したアプリを使い、許可された範囲で作業します。プロアクティブリサーチと呼ばれる背景作業では、接続済みアプリを読み取り専用の制限付きツールで使うと説明されています。また、重要な操作には自動レビューが入り、ユーザーの指示、Custom Rules、安全要件に照らして、進めてよい作業、承認が必要な作業、ユーザー自身が行うべき作業を判断します。パスワード変更のような一部の機密作業はユーザー側に残るとも明記されています。
この設計は、企業側のガバナンスにもそのまま使えます。すべてのdotに一律の権限を与えるのではなく、目的別に権限を分けるべきです。営業支援のdotはCRMと提案テンプレートを読めても、契約条件の確定や顧客への最終送信は承認必須にする。開発支援のdotはIssue、コード、CI結果を読めても、本番デプロイや権限変更は人間に残す。経理支援のdotは請求書案を作れても、支払い実行は人間承認にする。このように、読み取り、下書き、更新、送信、削除、支払いを分けることが重要です。
| 権限レベル | 代表的な作業 | 実務上の扱い |
|---|---|---|
| 読み取り | チャット、資料、CRM、Issueを読む | 初期導入しやすいが、機密範囲の棚卸しが必要 |
| 下書き | メール、提案書、PR、分析メモを作る | 人間レビューを前提に価値を出しやすい |
| 更新 | タスク、文書、チケット、社内DBを変更する | 対象システムと変更ログを明確にする |
| 外部送信 | 顧客、取引先、公開チャネルへ送る | 原則として承認または限定ルールが必要 |
| 高リスク操作 | 支払い、削除、権限変更、本番反映 | AI単独では実行させない設計が現実的 |
4. 常駐エージェントに任せやすい仕事、任せにくい仕事
dotsのような常駐エージェントに向いているのは、完了条件が比較的明確で、途中経過を確認でき、失敗しても巻き戻しや修正がしやすい仕事です。たとえば、顧客フィードバックの整理、会議後のタスク抽出、週次レポートの下書き、既存資料の更新候補作成、Issueの再現手順整理、コード修正案の作成、過去商談を踏まえた提案書ドラフトなどです。人間が毎回同じ確認をしているが、最終判断は残したい仕事ほど相性があります。
反対に、曖昧な責任判断、法務・労務・財務上の最終判断、顧客への重要な約束、本番データの削除、権限付与、支払い、重大インシデント対応の単独判断は任せにくい領域です。AIが下調べや論点整理をする価値はありますが、決裁や実行は人間側に残すべきです。常駐エージェントは「作業を任せる」には向いていても、「責任を移す」仕組みではありません。
導入初期は、次のような順序が現実的です。まず読み取りと下書きに限定し、利用ログと差し戻し理由を集めます。次に、社内向けの低リスク更新を許可します。たとえばチケットのラベル付け、社内メモの更新、レビュー依頼の作成などです。その後、明確なルールと承認ステップがある外部送信やシステム更新へ広げます。いきなり「AIが全部やる」状態を目指すより、どの仕事なら安心して委任できるかを段階的に見極める方が、現場にも管理部門にも受け入れられやすくなります。
ここで大切なのは、エージェントの性能だけを評価しないことです。よい導入判断には、作業時間の短縮、確認時間、差し戻し率、誤送信リスク、ログの追跡性、利用者の負担、セキュリティレビューの結果を一緒に見る必要があります。常駐エージェントの価値は、単発の回答精度ではなく、数日から数週間にわたる業務の流れをどれだけ乱さず支えられるかで決まります。
常駐AIエージェントは、読み取り、下書き、社内更新、外部送信、高リスク操作を段階的に分けて導入するのが現実的です。
5. 企業導入で先に作るべき承認と監査の型
dotsが示している未来は、AIエージェントが日常業務のすぐ近くに常駐する世界です。だからこそ、企業はツール選定の前に、承認と監査の型を用意する必要があります。どのアプリに接続できるか、どの部署のデータを読めるか、どの操作に承認が必要か、誰がログを見るか、問題が起きたときにどう止めるか。これらを後から整えると、現場の便利さと管理部門の不安がぶつかります。
第一に、dotごとの目的を明文化します。「営業を支援する」「開発を支援する」だけでは広すぎます。たとえば、営業なら「商談準備のためにCRM、過去提案書、製品資料を読み、提案書ドラフトと確認リストを作る」までを役割にする。開発なら「顧客フィードバックとIssueを読み、再現手順、修正方針、テスト案、PR案を作る」までにする。目的が明確なら、必要な権限も絞れます。
第二に、承認ルールを操作単位で分けます。AIがメールを下書きすることと、送信することは別のリスクです。AIがコードを修正することと、本番へ反映することも別です。OpenAIがCustom Rulesや自動レビューを説明しているように、企業側も「自動でよい」「承認が必要」「禁止する」を操作ごとに分ける必要があります。
第三に、ログを業務単位で残します。単にモデルの入出力を保存するだけでは、監査には足りません。どのdotが、どの目的で、どのアプリを読み、どの下書きを作り、誰が承認し、どの結果になったのかを追える必要があります。失敗時には、停止、巻き戻し、関係者通知、再発防止の流れも決めておきます。
導入前のチェックリストは次の通りです。
- dotごとの業務目的と責任範囲を1枚で説明できる
- 接続アプリ、参照データ、書き込み先を棚卸ししている
- 読み取り、下書き、更新、送信、削除、支払いの権限を分けている
- 自動実行、承認必須、禁止のルールを操作単位で決めている
- 外部送信や契約・請求・本番反映には人間承認を置いている
- 実行ログ、承認ログ、費用ログを業務IDで追える
- 失敗時の停止、巻き戻し、通知、再発防止の手順がある
- 個人用dotと組織用specialist dotの責任境界を分けている
6. まとめ
OpenAI dotsの発表は、AIエージェントが「会話で補助する存在」から「仕事を継続して預かる存在」へ移りつつあることを示しています。OpenAIの公式発表によると、dotsはGPT-6 Astraを基盤に、クラウドコンピューター、ブラウザー、接続済みアプリ、ChatGPT・Slack・Teamsでのやり取り、Custom Rules、自動レビュー、管理者有効化によるEnterpriseベータなどを備えています。さらに、組織専用のspecialist dotsやMicrosoft Agent 365との統合も視野に入っています。
企業にとっての論点は、導入するかどうかだけではありません。常駐エージェントに何を読ませ、何を作らせ、何を送らせ、どこで承認し、どのログで説明するかです。AIが先回りして働くほど、権限、承認、監査、停止条件の設計が価値を左右します。便利さだけを先に広げると、責任の所在が曖昧になります。逆に、過度に止めすぎると現場で使われません。
OpenBridgeでは、AIエージェント、RAG、業務システム連携、権限設計、監査ログ、運用コスト管理を組み合わせ、企業ごとの業務に合わせたAI基盤づくりを支援しています。dotsのような常駐型AIエージェントを活かすには、単に新しいツールを試すのではなく、自社の業務フロー、データ、承認文化、セキュリティ要件に合わせて「どこまで任せるか」を設計することが重要です。
これからのAI導入では、プロンプトの上手さだけでは差がつきません。人間が判断すべき仕事と、AIが継続して進められる仕事を分け、両者を承認とログでつなぐ企業ほど、AIを一時的な効率化ツールではなく、日常業務を支える実行基盤として使いこなせるようになります。


