OpenAI dotsの4つの行動ルール——承認と実行をどう分担するか

dotsは会話を終えた後も作業を続ける

OpenAIは2026年9月29日、常時稼働のエージェント「dots」を発表しました。

OpenAIの公式ドキュメントでは、dotsはGPT-6 Astraを搭載し、クラウド上に専用のコンピューターとブラウザを持つと説明されています。

クラウド上の作業は、利用者のパソコンの電源が切れていても続けられます。

一方、利用者のパソコンを接続して行う作業は、そのパソコンがオンラインで、ChatGPTアプリが開いている必要がある、とされています。

提供は段階的で、プランや地域によって条件が異なります。

チャットの回答を業務に使う場合にも、内容の確認は必要です。

さらに、外部のシステムを操作するエージェントでは、人が回答を読み直す前に、送信や更新まで進む場合があります。

しかも、人が画面の前にいない時間に動きます。

そのため、どの操作を許可し、いつ確認を求め、誰が実際に操作するかを決めることが、導入時の中心的な作業になります。

dotsの公式ドキュメント「Control your dot」は、この扱いを「カスタムルール」という設定に落とし込んでいます。

本稿では、会社が利用を認めたアカウントと接続先で、担当者が自分のdotsに仕事を任せる場面を想定します。

そのうえで、操作ごとの確認と実行の分担と、設定後の見直しを扱います。

公式ドキュメントに書かれている確認の仕組みと4つの選択肢

まず、ドキュメントに書かれていることを整理します。

操作の前に自動レビューが入る

OpenAIの説明では、dotsがアカウントに影響しうる操作や情報の共有をする前に、自動レビューが行われます。

このレビューは、利用者の指示、権限、カスタムルール、組み込みの安全要件に照らして、操作をそのまま進めてよいか、承認が必要か、利用者自身が行うべき手順を含むかを判断する、とされています。

文書中の例では、パスワードの変更は利用者自身が行う必要があります。

指示の出し方についても、具体的な記述があります。

継続的な指示には、誰が関わり、何が起き、いつ行うのかという範囲を明確に書くよう勧められています。

「返信の下書きを頼むこと」は「送信してよい」という許可にはならない、とも明記されています。

範囲が明確な指示は、その範囲内であれば将来の操作も対象にできますが、範囲の外の操作には別の判断が必要です。

カスタムルールの4つの選択肢

カスタムルールは、繰り返し行う操作の扱いを指定するための、任意の設定です。

設定の「パーソナライズ」にある「カスタムルール」で、操作を文章で書き、その扱いを選びます。

選べるのは次の4つです。

公式の英語表記	公式文書が説明する動作（筆者訳）
Take action without asking	指定した操作について、承認を求めずに実行する
Take action when you say so	明示的に依頼された操作を実行する。それ以外は実行の直前に確認する
Ask before taking action	指定した操作の前に承認を求める
Hand off to you	その操作を、利用者自身が行うよう求める

文書は例として、顧客へのメッセージ送信には「Ask before taking action」、共有プロジェクトファイルの削除には「Hand off to you」を挙げています。

また、会話の中で明確に指示を出すことから始めればよく、承認のたびにルールを作る必要はない、とも書かれています。

なお、「承認を求めずに実行する」を選んでも、組み込みの安全要件や、保存済みログインの利用承認のような必須の確認は残ります。

MIFはこの4つをどう読むか

ここからは、この4つを材料にした私たちの整理です。

4つの選択肢は、安全性が順番に高くなる目盛りではありません。

利用者自身が操作する設定でも、情報や判断が誤っていれば問題は起こりえます。

私たちは、この4つを次の三つの観点で見ています。

• どの指示を、操作への許可として扱うか: 事前に決めた範囲か、その操作を含む明示的な依頼か。
• 追加の確認をいつ求めるか: 確認を挟まないか、依頼の範囲外のときだけ直前に確認するか、毎回確認するか。
• その操作を実際に行うのは誰か: dotsか、利用者自身か。

特に、「Ask before taking action」と「Hand off to you」の違いは見落とされがちです。

前者は、利用者が承認したあと、操作するのはdotsです。

後者は、操作そのものを利用者が行います。

操作の影響や会社の業務ルールに応じて、この三つの組み合わせを選ぶ、というのが私たちの考え方です。

AIにできることはAIに任せ、人はAIと協働しながら、判断や最終責任を担う部分に集中する。

どこまで任せるかは、業務や時期に合わせて決めてよいものだと私たちは考えています。

カスタムルールと、接続先のアクセス権を分けて確認する

公式文書は、カスタムルールが特定の操作への許可を与えたり、確認を求めさせたり、操作を行わせないようにしたりできると説明しています。

同時に、保存したルールは「dotsが従おうとする指示」であり、dotsは間違える可能性がある、とも明記しています。

そして、カスタムルールは、アプリやコンピューターへのアクセスを与えるものではなく、組み込みの安全要件を上書きするものでもない、とされています。

つまり、区別すべきなのは、操作を進めてよいという「許可」と、接続先で実際に利用できる情報・操作の「範囲」です。

アプリ側の操作は「プラグインの権限」でカスタムルールとは別に管理される、と同じ文書に書かれています。

関連ページの例では、メールを読むことは許可しても、送ることは許可しない、という設定ができるとされています。

カスタムルールは、自動レビューが操作を判断する際にも参照されます。

したがって、ルールの記述、製品側の審査、接続先の権限を組み合わせて確認することになります。

ルールが自然言語の指示だから何の制御にもならない、とも、審査があるから問題ない、とも私たちは考えていません。

アプリの権限の設定についても、その設定が操作を禁止するのか、操作の前に確認を求めるのかを確かめておく必要があります。

操作の経路はプラグインだけではない

もう一つ確認したいのが、操作の経路です。

dotsは、アプリの接続だけでなく、クラウド上のブラウザでのログイン状態や、接続した利用者のコンピューターを使って作業することがあります。

管理者向けの文書も、接続先アカウントの権限と、クラウドブラウザのログイン状態を別々に確認するよう案内しています。

そのため、メールアプリ側の送信許可を制限したことだけで、業務全体として「送信できない」と結論づけないほうがよいと考えます。

これはdotsが制限を回避するという指摘ではなく、どの設定がどの経路に適用されるかを確かめる必要がある、という話です。

操作を制限する際は、プラグイン、ログイン済みのブラウザ、接続したコンピューターのどの経路からその操作が可能になるかを確認し、ルールと接続先の一覧を対応づけておくのが望ましいと考えます。

自社で埋める叩き台（一例）：操作ごとの割り当て表

ここまでを、表にしてみます。

これはMIFが示す割り当ての一例であり、製品の必須設定や、安全性が保証された設定ではありません。

どの操作をどう扱うかは、自社の業務、取引先との関係、関係する法令、誤操作による影響によって変わります。

対象と範囲を絞った操作の例として、自社の操作を埋めていくための叩き台に使ってください。

条件を絞った操作	ルールの選択例	あわせて決める・確認すること
指定した資料から、本人用の下書きを作る	確認なしで実行	使う資料と保存先を限定する。共有や送信は含めない
明示的に指定した社内の宛先へ、日程調整の連絡を送る	指示があれば実行	宛先、内容、日程、送信に使うアカウントを確認する。招待を送る場合はカレンダー側の操作も確認する
顧客へ連絡を送る	実行前に確認	宛先、本文、添付ファイルを確認する。社内の承認が必要なら、その手順も満たす
共有ファイルを削除する	利用者自身が実行	dotsに削除を任せない運用とあわせて、接続先で実際に許可されている操作を確認する
見積・請求の金額を確定する	この例では人が判断・確定	dotsの担当は数字の整理までとする。確定済みの文書を送る操作は、別の操作として扱いを決める

パスワードの変更は、この表のような任意の割り当てではなく、製品が利用者自身の操作を求める例として文書に挙げられています。

製品の確認と、社内の承認は別に対応づける

「Hand off to you」は、利用者自身に操作を求める選択肢です。

上司や経理の責任者へ承認を回す機能ではありません。

そのため、dotsの画面で利用者が承認したことと、会社の決裁の条件を満たしたことは、同じとは限りません。

製品が利用者に求める確認と、会社の業務上必要な承認を対応づけておき、利用者自身に決裁権がない操作は、社内の承認手順を別に確認するのが望ましいと考えます。

表を埋める前に決めておくこと

同じ表を埋めるときに、先に決めておきたい項目が三つあります。

• 操作の棚卸し: dotsに任せたい仕事を、「読む」「下書きする」「送る」「更新する」「削除する」のように、操作単位に分ける。見積なら「数字の整理」「金額の確定」「確定した文書の送付」は別の操作として扱う。
• 指示の範囲: 継続的な指示に、誰が関わり、何をし、いつ行うかを書く。
• 影響の見積もり: 復元や訂正のしやすさは判断材料の一つにとどめ、扱う情報、影響を受ける相手、処理する件数、誤りに気づけるまでの時間もあわせて確認する。

復元できることと、その間に生じた影響を取り消せることは別だからです。

たとえば、共有資料を誤って書き換えてもファイル自体は戻せるかもしれませんが、その内容を同僚がすでに読んで作業を進めていれば、ファイルを戻すだけでは影響は消えません。

一件なら直しやすい操作でも、多数の記録に繰り返し適用されれば、確認と復旧の負担は変わります。

設定、動作確認、見直しを一続きで設計する

私たちは、最初の設定、実際の動作確認、その後の見直しを、一続きの作業として設計することを勧めます。

利用を始める前に、動作を確かめる

設定したことと、意図どおりに動くことは別です。

利用を始める前に、影響を限定した環境で、たとえば次の点を確かめておくとよいと考えます。

• 下書きを頼んだときに、送信まで進まないか。
• 指定した範囲を超える操作で、確認を求めるか。
• 承認を却下した操作が、実行されないか。

もちろん、この確認に通ったことだけで、将来のすべての動作が保証されるわけではありません。

実行中の作業の停止、予約の解除、結果の修正を分ける

止め方も、設計の段階で決めておきたい項目です。

公式文書は、停止の操作による違いを説明しています。

「Pause」は、dotsの現在のメインのタスクを止めますが、委任したタスクのすべてを止めるわけでも、今後の予約実行を取り消すわけでもありません。

委任したタスクはActivityで個別に確認して止め、繰り返しのタスクはScheduledで無効化または削除します。

そして、停止や削除の操作だけでは、すでに実行した変更は取り消されません。

dotsを削除しても、接続先のアプリですでに行われた変更や、すでに他の人に届いたメッセージは取り消されない、とされています。

結果の確認と、可能な範囲での復旧・訂正は、停止とは別の手順として用意しておくのが望ましいと考えます。

Activityを見る担当と、見るものを決める

確かめる手段として、文書は「Activity」の画面を挙げています。

デスクトップアプリでdotsのプロフィールを開くと、タスクの進行、ファイル、結果を確認でき、承認や入力を待っている依頼にも応答できます。

「Scheduled」では、予約されている繰り返しのタスクの指示、タイミング、宛先を確認できます。

ただし、画面を見られることと、確認が済んだことは別です。

公式文書にも、実行が完了した表示だけでは、求めた結果が達成・送付されたとは確認できない、という注意があります。

見直しの担当者を決め、想定外の操作、承認を求めた理由、実行結果を確認し、ルールや接続の設定を変えたときはその内容を記録しておくことを勧めます。

見直しのきっかけ

見直しのきっかけとして、次のようなものが考えられます。

• 承認の依頼が多いとき: 件数だけを理由に確認を省くのではなく、依頼の範囲、重複している確認、通知の出し方、対象業務の分け方を見直す。承認を減らす場合も、必要な判断を省いていないかを確かめる。
• 想定外の実行や、承認の却下があったとき: 却下の理由とともに記録し、ルールの文面や指示の範囲を直す材料にする。
• 接続の追加・変更: アプリ、Slack、コンピューターを足したとき。アプリやコンピューターの接続はカスタムルールとは別に管理されるため、接続を足すたびに、利用できる操作の範囲が広がりえます。
• 担当者の異動・退職: 管理者向けの文書によれば、アプリの接続を外しても、すでに取得された情報は削除されません。現在利用できる削除・初期化の方法と、その対象範囲を、引き継ぎの手順の中で確認しておく必要があります。
• 製品の更新: 管理者向けの文書では、dotsの利用権限が「Use dots (Beta)」と表記されています。設定項目や挙動が変わることを前提にしておくのが安全です。

記録については、管理者向けの文書が、Compliance APIの記録で利用者のメッセージとdotsの返信を調べられるとしつつ、監査に頼る前に記録の対象範囲を確認するよう注意しています。

会話の記録があることと、すべての操作の監査証跡がそろっていることは別です。

どの記録をどこまで残し、誰がいつ見直すかは、自社側で決める部分だと私たちは考えます。

まとめ

私たちは、AIに仕事を任せる際、操作ごとに対象と範囲を決め、どの指示で実行を許可し、どの場面で追加の確認や利用者自身による操作を求めるかを整理することを勧めます。

dotsのカスタムルールの4つの選択肢は、その整理を設定に落とすための手段の一つです。

判断の際は、復元できるかどうかだけでなく、扱う情報、影響を受ける相手、処理の件数や頻度も確認します。

決めた扱いをカスタムルールと接続先の設定に対応づけ、製品の確認と社内の承認も対応づけたうえで、実際の動作を確かめます。

利用を始めたあとは、接続先、業務、管理設定の変更に応じて見直します。

実行中の作業を止める手順、予約を解除する手順、実行結果を確認して修正する手順も、あわせて整理しておきます。

最初にできることは、dotsに任せたい仕事を操作単位に分け、それぞれの影響を書き出すことです。

情報確認について

本記事は、OpenAIの発表「Introducing dots」と、公式ドキュメント「Control your dot」（ChatGPT Learn）を主要な参照元として、2026年10月3日確認時点の情報をもとに作成しています。

あわせて、同ドキュメント群の「Tasks and memory」「Connect computers and apps to your dot」、および管理者向けの「Manage dots permissions and capabilities」を参照しました。

dotsの提供状況（プラン、地域、管理者による有効化の要否）、機能、画面上の表記は変更される可能性があります。

ルールの動作についての記述は、OpenAIの公表資料に基づく整理であり、私たちが実機で挙動を検証したものではありません。

表中の日本語訳は筆者によるものです。

4つの選択肢の読み方、操作ごとの割り当て表、動作確認と見直しの観点は、MIFによる整理であり、OpenAIの説明ではありません。

導入を検討する際は、OpenAIの公式情報とご自身の環境で最新の状況をご確認ください。