2026.09.30 ChatGPT

OpenAI Dotsとは？常時稼働エージェントの権限設計と自社システム接続【2026年9月】

OpenAIが2026年9月29日（米国時間）のDevDay 2026で発表したdotsは、GPT-6 Astraを搭載し、専用のクラウドコンピューターで24時間働き続けるエージェントです。この記事では、OpenAI Dotsの仕様と対象プラン、ChatGPT WorkやCodexとの違い、操作権限を決める3層の仕組み、企業で問題になりやすいデータの扱い、そして自社システムをdotsに触らせるためのMCPサーバー実装までを、公式ドキュメントの記載だけで組み立てます。なお公式表記は小文字の「dots」で、1体を指すときは「dot」です。

まとめ：OpenAI Dotsを業務に入れる前に決める権限・データ・接続の3点

dotsは「質問に答えるAI」ではなく、目標を渡すと会話の合間にも作業を進める常駐型のエージェントです。導入の可否は性能より運用設計で決まります。

先に決めるのは3つです。1つめは権限で、プラグインの権限・Custom Rules・組み込みの安全要件という3層のうち、利用者が変えられるのは上の2層だけ。パスワード変更と口座間の送金は、どう設定しても人が引き取ります。2つめはデータで、dotが覚えた個別の記憶は閲覧も個別削除もできず、消す手段はdotごとの削除しかありません。3つめは接続で、社内の基幹システムをdotsに触らせる正規の経路はプラグイン（MCPサーバー）です。読み取りと書き込みをツール単位で分け、認可をサーバー側で判定する作りにすれば、dotsの承認フローと社内の統制を両立できます。

OpenAI Dotsの基本仕様｜GPT-6 Astra搭載・対象プラン・作成手順

まず、発表時点で確定している仕様を押さえます。数値と条件はすべて2026年9月30日時点の公式情報です。

専用クラウドPCとGPT-6 Astraで24時間動く常時稼働の仕組み

OpenAIのdots発表によると、各dotは自分専用のクラウドコンピューターとブラウザーを持ち、利用者のPCが電源オフでも作業を続けます。頭脳はGPT-6 Astraで、フィードバックから好みや判断基準を学び、頼まれる前に動くこともあります。モデル側の仕様と提供経路はGPT-6 Astraの料金とデータ境界を整理した記事で扱いました。

指示はChatGPT・Slack・Teamsから文字か音声で出し、プラグイン経由で4,000を超えるアプリにつながります。1体が複数のプロジェクトを並行して抱え、スレッドをまたいで文脈を保つ点が従来のチャットとの差です。

Pro・Business Premium・Enterpriseベータの対象プラン条件

提供対象は、対象地域のProとBusiness Premiumです。Enterprise（EduとHealthcareを含む）はベータ扱いで、DevDay 2026のまとめでは既定でオフ、ワークスペース管理者が有効にして初めて使えると書かれています。最初の1体はプランに含まれ追加料金はかかりません。より重い作業向けの利用枠もプランに含まれ、提供開始から1か月は上限が拡大されます。

日本が対象地域に入るかは、9月30日時点で公式に国名の一覧が無く未確認です（詳細はFAQで扱います）。

デスクトップで作成しモバイルで話す初期設定の4手順と通話・SMSの制約

Help Centerの「Getting started with your dot」に沿うと、作成はChatGPTのデスクトップアプリ（Windows版を含む）かデスクトップのブラウザーで行います。モバイルでは作成できず、モバイルWebは非対応です。

デスクトップでdotを作成し、名前とアバターを決める（既定のハンドルは @yourname-dot）
使わせるアプリをプラグインとして接続し、許可する操作を確認する
SlackやTeamsなどの連絡経路をデスクトップから設定する
設定後はモバイルアプリからも話しかけられる

発表のデモでは電話で会話していましたが、Help Centerでは提供開始時点でdotから利用者へ電話をかける機能は無いとされています。テキストメッセージ連携も米国のProに限った限定ベータで、BusinessとEnterpriseでは使えません。

ChatGPT WorkやCodexとの違いと利用上限・プラグイン権限の共有範囲

OpenAIには作業を任せる製品が既に複数あります。dotsはそれらを置き換えるのではなく、上に立って仕事を振る位置づけです。

dotsが司令塔になりWorkやCodexへ作業を振る役割分担

ChatGPT Workの仕組みを解説した記事で見たとおり、Workは1つの依頼を分解して成果物まで運ぶエージェントです。dotsはその外側にいて、目標を持ち続け、必要に応じてWorkやCodexのタスクを自分で起こします。コードの作業では、Codexで先に用意したクラウド環境を指定して、リポジトリ上の修正やテストを任せられます。

違いを1行で言えば、Workは「依頼ごとの実行者」、dotsは「目標ごとの担当者」です。会話が終わっても仕事が続くかどうかが分かれ目になります。

dotとの会話は上限外でWork・Codexへの委任タスクは上限に数える境界

費用の見積もりで効くのがここです。発表では、dotとの会話はChatGPTの利用上限に数えない一方、dotにCodexやChatGPT Workのタスクを起こさせた場合は通常どおり上限に数えると明記されています。

話すだけなら枠は減らず、手を動かす作業ほど消費します。定期タスクを任せるなら、上限拡大の1か月が終わる前にdot経由の消費実績を確かめておくのが安全です。

ChatGPT・Work・Codexと共通になるプラグイン権限の範囲

dotsのプライバシーと安全性に関するFAQによると、プラグインの権限はdots・ChatGPT・ChatGPT Work・Codexで共有されます。ChatGPTでGmailやGoogle Driveを接続済みなら、dotはその接続を許可された範囲でそのまま使えます。

ChatGPT用に広く許可した権限が、自分から動くdotにもそのまま効くということです。閲覧は許すが送信は許さない、といった操作単位の許可は既存の管理画面で分けられるので、dotを作る前に権限を棚卸ししてください。

dotsの操作権限を決める3層｜プラグイン権限・Custom Rules・安全要件

dotsが勝手に何かを送ったり消したりしないかは、3つの層の組み合わせで決まります。上の層ほど利用者が変えられ、下の層は誰にも変えられません。

Custom Rulesで選べる4つの動作区分と設定できない範囲

「Control your dot」のドキュメントでは、Custom Rulesで操作ごとに次の4つから動作を選べます。

区分	dotの動き	向く操作の例
確認せず実行	承認なしで実行	社内チャンネルへの定型報告
指示時のみ実行	明示の依頼時だけ実行	指定した相手への返信
事前に承認	実行前に毎回承認を求める	顧客へのメール送信
人に引き渡す	人に作業を渡す	共有ファイルの削除

ルールはdotが従おうとする指示であり、アプリへのアクセス権を与えるものではありません。組み込みの安全要件、auto-reviewという別系統の確認、後述するプロアクティブリサーチの制限は、Custom Rulesでは外せません。ワークスペース側でCustom Rulesを無効にすると、保存済みのルールも適用されなくなります。

パスワード変更や送金は必ず人に戻し完全削除は毎回承認とする安全要件

最下層の安全要件は固定です。FAQでは、パスワード変更と口座間の送金は必ず人が引き取り、データの完全削除やソフトウェアのインストールは毎回の承認が要るとされています。dotsの安全設計を解説したOpenAIのブログでは、出所が確認できないソフトの実行や、新たなセキュリティ上の権限付与も毎回承認の対象に挙がっています。保存済みカードでの購入も承認が必要です。

情報の共有には、データの機微度に応じた宛先の指定が求められます。健康情報は「〇〇医師へ」と名指しの宛先が必須で、メールアドレスや電話番号のような機微度の低い情報は「航空会社全般」のような宛先の種類で足ります。一度の承認は、その依頼の範囲を越えて広がりません。

接続アプリを読むだけで読み取り専用がコードで強制されるプロアクティブリサーチ

dotは頼まれていない間も、接続済みのアプリを調べて手伝えることを探します。OpenAIの呼び名は「プロアクティブリサーチ」。同じブログによると、この調査は読み取り専用のツールだけで動き、他人へのメッセージ送信・アプリ内容の変更・ブラウザーやPCの操作ができないようコード側で強制されています。

調査の結果を受けてdotが動く場合は、通常の権限と承認の流れに戻ります。裏を返せば、読み取りを許可したアプリの中身は、利用者が何も頼まなくてもdotに読まれ、記憶として残りうるということです。この性質が次章のデータの扱いに直結します。

企業導入で確認するデータの扱い｜学習・メモリ共有・削除できない範囲

情報システム部門が最初に確認するのは、学習への利用と、残ったデータを消せるかどうかです。後者に落とし穴があります。

BusinessとEnterpriseは既定で学習対象外という学習利用の条件

ChatGPT Business・Enterprise・Eduのワークスペースの内容は、既定でモデルの学習に使われません。個人向けプランは「Improve the model for everyone」の設定で選べます。プロアクティブリサーチのメモは直接の学習対象外で、会話に持ち込まれた部分だけが設定に従います。

見落としやすいのは人によるレビューです。FAQには、学習を無効にしていても安全上の理由など限られた状況では人がdotの活動を確認しうると書かれています。契約上「第三者の目に触れない」ことを求められる業務データを扱うなら、この1文を法務と共有しておくべきです。

個別の記憶を閲覧も削除もできずdotごと削除するしかないメモリの制約

企業利用で最も重いのがここです。FAQでは、dotが覚えた個別の記憶を閲覧・削除・修正する手段は現時点で無く、消すにはdot自体を削除するしかないとされています。プラグインを切断しても新しい読み取りが止まるだけで、既に取り込んだ情報は残ります。

操作	消えるもの	残るもの
プラグインの切断	以後の新しい読み取り	取り込み済みの文脈
ChatGPTのMemoryをオフ	以後のメモリ共有	dotが受け取り済みの情報
dotの削除	dot自身の文脈・記憶・定期タスク	作成したファイル・Codexスレッド・会話

dotの文脈には認証情報・画像・スクリーンショットは残らないとされています。ただし顧客から個人情報の削除を求められたとき、特定の記憶だけを消して証跡を示すことはできません。個人情報を含む受信箱や顧客管理システムをdotに読ませる設計は、この削除要件を満たせるかを先に詰めてください。

dotを削除や一時停止しても連携先の変更と委任タスクは戻らない範囲

削除の効果はdotの内側に閉じ、連携先アプリで行った変更も送ったメッセージも戻りません。一時停止で止まるのは現在のメインタスクだけです。運用手順書には、dotの一時停止・Activityからの委任タスク停止・Scheduledからの定期タスク無効化の3操作を分けて書いておきます。

自社システムをdotsに触らせるプラグインのMCPサーバー実装手順

dotsが使えるのは、アカウントに導入・有効化されたプラグインです。社内の受発注や在庫の仕組みをdotsから扱わせたいなら、自社でプラグインのMCPサーバーを用意するのが正規の経路になります。

読み取りと書き込みをツール単位で分けるMCPツール設計と安全注釈の判断基準

OpenAIのツール定義のガイドは、権限・安全上のリスク・承認の要否が異なる操作は別のツールに分け、読み取りと書き込みを区別するよう求めています。注釈は実際の動作どおりに付けます。readOnlyHint は状態を変えないときだけ true、destructiveHint は元に戻しにくい結果を生むときに true です。定義の原典はMCP仕様のスキーマリファレンスにあります。

dotsのプロアクティブリサーチが読み取り専用のツールをどう判別しているかは、公開文書には書かれていません。注釈に頼って安全を担保するのではなく、書き込みを別ツールに切り出し、サーバー側で必ず認可する構造にしておけば、判別方法に左右されません。ガイドも注釈はサーバー側の認可や入力検証の代わりにならないと明記しています。

TypeScriptで注文照会と取り消しを分けたMCPサーバーの最小コード

公式の「Build an MCP server」の書き方に沿った最小構成です。照会は読み取り専用、取り消しは破壊的操作として別ツールにしています。

npm install express @modelcontextprotocol/sdk zod
npx tsx server.ts

import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { z } from "zod";

// 検証用のダミーデータ（本番は社内DBへ置き換える）
const orders = new Map([
  ["A-1001", { id: "A-1001", status: "shipped" }],
  ["A-1002", { id: "A-1002", status: "pending" }],
]);

function buildServer() {
  const server = new McpServer(
    { name: "acme-orders", version: "1.0.0" },
    { instructions: "注文を変更する前に get_order で現在の状態を確認すること。" }
  );

  // 読み取り専用：状態を変えないので readOnlyHint を true にする
  server.registerTool(
    "get_order",
    {
      title: "注文の状態を確認",
      description: "注文番号から現在の出荷状態を調べるときに使う。",
      inputSchema: { orderId: z.string().regex(/^A-\d{4}$/) },
      outputSchema: { id: z.string(), status: z.string() },
      annotations: { readOnlyHint: true, destructiveHint: false, openWorldHint: false },
    },
    async ({ orderId }) => {
      const order = orders.get(orderId);
      if (!order) {
        return { isError: true, content: [{ type: "text", text: `注文 ${orderId} は見つかりません` }] };
      }
      return { structuredContent: order, content: [{ type: "text", text: `${orderId}: ${order.status}` }] };
    }
  );

  // 書き込み：取り消しは戻せないので destructiveHint を true にし、照会とは別ツールにする
  server.registerTool(
    "cancel_order",
    {
      title: "注文を取り消す",
      description: "未出荷の注文を取り消すときだけ使う。出荷済みには使えない。",
      inputSchema: { orderId: z.string().regex(/^A-\d{4}$/) },
      annotations: { readOnlyHint: false, destructiveHint: true, openWorldHint: false },
    },
    async ({ orderId }) => {
      const order = orders.get(orderId);
      // 業務ルールと認可はモデルに任せずサーバー側で判定する
      if (!order || order.status !== "pending") {
        return { isError: true, content: [{ type: "text", text: `${orderId} は取り消せません` }] };
      }
      order.status = "cancelled";
      return { content: [{ type: "text", text: `${orderId} を取り消しました` }] };
    }
  );
  return server;
}

// ステートレス構成：リクエストごとにサーバーとトランスポートを作る
const app = express();
app.use(express.json());
app.post("/mcp", async (req, res) => {
  const server = buildServer();
  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
  res.on("close", () => {
    transport.close();
    server.close();
  });
  await server.connect(transport);
  await transport.handleRequest(req, res, req.body);
});
app.listen(3000);

入力の注文番号は正規表現で形式を縛り、取り消し可否は未出荷かどうかをサーバーが判定します。dotが「取り消して」と判断しても、業務ルールに合わなければ実行されません。なおこのコードはOpenAIのガイドと同じv1系の @modelcontextprotocol/sdk を使っています。v2ではパッケージ名が分かれており、移行時の差分はMCP TypeScript SDK v2の移行要点をまとめた記事にまとめました。

顧客データや書き込みを扱うときに必須となるOAuth 2.1認証

上のコードは認証を省いた検証用です。プラグインの認証ガイドは、顧客固有のデータや書き込み操作を公開するMCPサーバーでは利用者を認証し、MCPの認可仕様に沿ったOAuth 2.1を実装するよう求めています。MCPサーバーはアクセストークンをリクエストごとに検証する側に立ち、保護リソースのメタデータを /.well-known/oauth-protected-resource で公開します。

スコープは読み取りと書き込みで分けるのが基本です。照会だけを許すトークンなら、dot側の設定がどうであれ取り消しは通りません。既存の社内SaaSで同じ考え方を実装した例として、Slack MCPサーバーの権限設計を扱った記事も参考になります。

管理者が先に設定するワークスペース権限とローカルPC接続・Agent 365連携

Enterpriseでは既定でオフのため、利用者より先に管理者の作業が発生します。

ローカルPC接続は機能ごとの個別opt-inで同時接続は1台までという条件

dotは既定で自分のクラウドPCだけを使い、利用者のPCへの接続は後から許可する方式です。アプリとPCの接続に関するドキュメントでは、同時に接続できる個人のPCは1台までで、接続中はPCをオンラインにしてChatGPTアプリを開いておく必要があります。

管理側では、Work CloudとdotsのローカルPCアクセスの管理ガイドのとおり、Workspace settingsのPermissions & rolesで機能ごとに個別に有効化します。Workで許可してもdotsには及びません。実行時の制限はAdmin ConsoleのAgent Security（旧Policies & Configuration）で一元管理し、MDMによる端末側の制御がそれより優先されます。開発者のPCでビルドやテストまで任せるなら、ここで許すコマンドとネットワークの範囲を先に決めておきます。

組織の業務を担う専門dotsのパイロットとAgent 365連携の現状

個人の分身とは別に、組織内の決まった業務を担う「専門dots」も発表されました。企業が各dotに固有のIDと認証情報を与える形で、OpenAI社内では調達や請求書処理などで試験運用したとされています。提供は企業向けの個別パイロットからです。

MicrosoftとはAgent 365のガバナンス機能と統合する取り組みが進行中です。Agent 365でエージェントを登録・管理する流れはMicrosoft Agent 365で自社エージェントを登録する手順の記事で整理しました。Microsoft 365中心の組織は、統合を待ってから専門dotsを検討しても遅くありません。

OpenAI Dotsを採用してよい業務と見送る業務の判断基準

最後に、条件つきで結論を出します。

既存の公式プラグインで完結する担当者個人の定常業務は採用してよい条件

採用してよいのは、GmailやGoogle Drive、GitHubなど既に公式のプラグインがあるSaaSの中で完結し、担当者本人の仕事を肩代わりする業務です。会議資料の更新、問い合わせの定期チェック、Issueの調査とプルリクエストの下書きは、この条件を満たします。dotとの会話は利用上限に数えないため、まず会話と下調べから任せ、Work・Codexの消費を見ながら範囲を広げる順序が無理のない入り方です。

個人情報の削除要求に応える業務と基幹データの書き込みは見送る場面

見送るのは2つの場合です。1つは、顧客の個人情報を含む受信箱や顧客管理システムを読ませる業務。個別の記憶を消せない以上、削除要求に「その情報だけ消した」と答えられません。もう1つは、基幹システムへの書き込みをブラウザー操作で代行させる計画で、業務ルールをサーバー側で縛れず、防波堤がdotの判断だけになります。「まず本番の顧客データで試す」は避けるべき失敗パターンです。

社内の基幹システム連携をMCPサーバーの受託開発で作り込むべき要件の線引き

基幹データをdotsから扱わせたい要件が残るなら、前章のように読み取りと書き込みを分けたMCPサーバーを自社で持つのが筋です。工数がかかるのはツールの数より、認可・スコープ・監査ログ・削除要件といった統制の設計のほう。社内に実装経験が乏しければ、要件が固まった段階でAIエージェント開発の相談窓口に持ち込むと、プラグイン設計から権限の棚卸しまで一度に進められます。

OpenAI Dotsの導入検討でよくある質問と公式情報に基づく回答

発表直後に多い疑問に、2026年9月30日時点の公式情報で答えます。

OpenAI Dotsは日本で使えますか？

OpenAIは提供先を「対象地域（eligible markets）のProとBusiness Premium」と説明していますが、9月30日時点で国名の一覧は公式に見当たらず、日本が含まれるかは確認できていません。ChatGPTのデスクトップアプリかデスクトップのブラウザーで、dotの作成画面が表示されるかどうかで確かめるのが確実です。

OpenAI Dotsの料金はいくらかかりますか？

最初の1体はProまたはBusiness Premiumのプランに含まれ、追加料金はかかりません。重い作業向けの利用枠もプランに含まれ、提供開始から1か月は上限が拡大されます。dotとの会話はChatGPTの利用上限に数えませんが、dotがCodexやChatGPT Workで起こしたタスクは通常どおり数えます。追加のdotや作業量の拡大は将来提供予定とされ、価格は未公表です。

dotsとChatGPT Workは何が違いますか？

ChatGPT Workは依頼ごとに成果物まで仕上げる実行役で、dotsは目標を持ち続けて会話の合間も作業を進める担当者の役です。dotsは必要に応じて自分でWorkやCodexのタスクを起こします。プラグインの権限は共通なので、Workで許可した操作はdotにも効きます。

dotsが勝手にメールを送ったりデータを消したりしませんか？

送信や共有の前にはauto-reviewが指示・権限・Custom Rules・安全要件と照合し、実行・承認待ち・人への引き渡しを振り分けます。データの完全削除やソフトのインストールは毎回承認が必要で、パスワード変更と送金は必ず人の手に戻る仕組みです。Custom Rulesで「メールは送らない」といった制限も足せますが、dotも誤ることがあるため、影響の大きい作業は結果を確認する前提で使います。

dots.mocrやdots.ocrとOpenAI Dotsは関係がありますか？

関係ありません。dots.mocrとdots.ocrは、rednote-hilabが公開している文書OCR向けのモデルで、OpenAIのエージェントとは別の製品です。名前が似ているため検索結果が混ざりやすく、OCRモデルの性能や導入手順を調べている場合はdots.mocrの精度と導入手順を解説した記事が該当します。