ぶるすなさんChatGPTのdotに毎日の仕事を任せていると、確認待ちで止まる、報告が細る、古い基準で点検される、といったことが起きます。
この記事では、2026年10月5日から約1か月、毎日dotを回した自分の運用記録から、「どこまで任せ、どこで確認するか」の勘所を小ワザ10個にまとめます。
dotとは何か、対象プラン、費用は別の記事に任せ、ここでは毎日の確認だけを扱います。
dotの「完了」表示で終わらせず、受領した報告をIDで突き合わせ、採否はdotに任せない。これが、約1か月続けて残った線引きです。
- 受領した報告ファイル(11-05朝の累計)
2,026本 - 受領が最多の日
324本(10-26) - 候補の採用の割合(10-25時点・643本分)
31.7% - 誤りの記載がある報告(10-25までの7日)
16本(実質約12本)
止まり方確認待ちで全体が止まったのは4回(10-23、10-25、10-26の2回)。
10-31〜11-02は報告が25本・25本・35本に細り、調べ始めるまで約2日かかりました。原因の説明はdotの自己申告です。
未確認作業時間の節約量、報告をそのまま使えた・直した・捨てた割合、スマホの画面、カスタムルールの設定画面の実物。
本数はdotから受領した報告ファイルの数で、当たりの数ではありません。数え方は各小ワザの表に書きました。
注意数字は、ChatGPT Proでdotを1体使い、Claudeを統括役にした自分の運用での記録です。ほかの環境の結果を示すものではありません。
dotは誤ることがあります。売買の判断は任せないでください。
こっちゃんdotに毎日任せるって、結局どこまで任せていいの?
ぶるすなさん任せること、確認すること、任せないことの3つに分けて考えているよ。
10個の小ワザは、最後の図でこの3つに分けて見直します。
まずは、1か月の数字から見ていこう。
dotの毎日の納品を確認する小ワザ10選(約1か月の運用記録から)
① 受領の本数は、数え方を決めて日別に見る
ぶるすなさん【使いどころ】dotがどれだけ報告を出しているかを、受け取った側の数で確かめたいとき。
【やること】受領した報告ファイルの数を、ファイル名の日付で日別に数えます。依頼の本数やdotの自己申告ではなく、受け取った数で見ます。
【結果】10-14〜11-04の22日で合計1,936本、最多は10-26の324本でした。11-05の朝の時点で、受領した報告ファイルは累計2,026本です。
【注意】本数は報告の数で、当たりの数ではありません。累計との差の90本は、10-13以前の82本と11-05朝の8本です。日別の数字は同じ基準で数え直したため、当時の途中集計とは違う日があります。

| 日付 | 受領(本) | 同じ日の記録 |
|---|---|---|
| 10-14 | 52 | — |
| 10-15 | 39 | — |
| 10-16 | 48 | — |
| 10-17 | 100 | — |
| 10-18 | 201 | — |
| 10-19 | 114 | — |
| 10-20 | 98 | — |
| 10-21 | 26 | — |
| 10-22 | 40 | 依頼を書いたファイルが1.28MBに(小ワザ⑤) |
| 10-23 | 46 | 確認待ちで全体が停止(小ワザ③) |
| 10-24 | 160 | — |
| 10-25 | 128 | 18:04から確認待ちで報告が停止 |
| 10-26 | 324 | 最多。確認待ちの停止が2回あり、画面から承認して再開 |
| 10-27 | 46 | — |
| 10-28 | 23 | — |
| 10-29 | 48 | — |
| 10-30 | 102 | — |
| 10-31 | 25 | 細りの1日目(小ワザ⑥) |
| 11-01 | 25 | 細りの2日目 |
| 11-02 | 35 | 細りの3日目。夜に納品状況を調べ、dotの説明を得た |
| 11-03 | 152 | 承認範囲を送り直したあと |
| 11-04 | 104 | — |
| 合計(22日) | 1,936 | — |
りっちゃん本数が多いほどいい、ってわけでもないのよね?
ぶるすなさんそうなんだ。本数は受け取った報告の数で、中身の良し悪しは別だよ。
採用の割合は、小ワザ⑧で「候補の数」として見るよ。
② 完了と出ても、受領をIDで突き合わせる
ぶるすなさん【使いどころ】dotの「完了」や「保存しました」を、そのまま信じてよいか迷うとき。
【やること】依頼にID(DR-日付-番号の形)を付け、報告のファイル名にも同じIDを入れてもらいます。受領のたびにIDで突き合わせ、済みにします。
【結果】IDの無かった10-06は、資料5本のうち3本を夜まで見つけられませんでした。10-28には「在庫221本」と数えていたものが、実際は2本だったこともあります。
【注意】公式ヘルプも、完了と表示されたあとに結果を確認するよう案内しています。IDの形は、小ワザ③の画面で見られます。
| 日付 | 起きたこと | 決めたこと |
|---|---|---|
| 10-06 | 依頼IDの無い資料5本のうち、3本を夜まで見つけられなかった | 依頼IDを必須にし、報告のファイル名にも入れる |
| 10-28 | 「在庫221本」と数えていたが、実際は2本だった。受領済みのものが、未処理のまま残っていた | 受領のたびにIDで済みにする |
| 毎日 | dotの完了や保存の表示 | 受領した報告をIDで突き合わせる。公式ヘルプも、完了と表示されたあとに結果を確認するよう案内している |
③ 確認待ちで全体が止まったら、画面の確認カードで解く
れおしゃん会話で「いいよ」と返すだけじゃ、dotは動いてくれないの?
ぶるすなさん自分の記録では、会話で許可を伝えても再開せず、確認カードを確定したあとで再開したよ。
【使いどころ】報告が急に止まり、dotが何かの確認を待っていそうなとき。
【やること】dotの発言を読み、どの操作の確認待ちかを特定します。画面に出る確認カード(カスタムルールの確認)を確定して、初めて承認が効きました。範囲内の作業は事前承認にし、確認が要るものはその1件だけ止める決まりにしました。
【結果】10-23・10-25・10-26(2回)の計4回、確認待ちで全体が止まりました。10-25の18:04から報告が止まり、dotは画像の保存と新規制作の承認を待っていました。10-26に画面から承認して再開しています。
【注意】下の画面は11-05の実物です。9:02と10:07の2件は、報告Docを新規作成・保存してよいかを1件ずつ尋ねています。対策のあとで止まる回数が減ったかは、記録がなく言えません。

りっちゃん朝のまとめの方は、どこまで確かめたかを書き分けているのね。
ぶるすなさんうん。6:54の朝のまとめでは、受領した31件を「すべて未判定」、点検の候補を「実行・再現はしていない」と書き分けていたよ。
ただ、これはdotの自己申告です。裏づけは、受け取った側で取ります。
④ 「Claudeから」の承認が受け付けられなかった
こっちゃんClaudeが代わりに「承認します」って送れば済まないの?
ぶるすなさん自分もそう考えたんだけど、通らなかったよ。
【使いどころ】Claudeを統括役にして、dotへの承認もClaude経由で送るとき。
【やること】承認が要る場面は、持ち主である自分の一言が要る前提で段取りします。
【結果】11-03の11:30、dotは「Claudeから」と書いた承認を、持ち主の承認として扱いませんでした。自分の了承を得てClaudeが送った修復の承認に、dotは本人から一言ほしいと返しました。名乗りを外して送り直すことはせず、自分が1行送る形にしました。
【注意】dotが内部でどう判断したかは分かりません。見えたのは、返事の文面だけです。
| 公式の説明(言い換え) | 自分の運用での受け止め |
|---|---|
| 下書きを頼んだだけでは、送信を許可したことにならない | 「書いて」は「送ってよい」ではない |
| 事前承認済みとは、その操作をプロンプトで明示的に頼んだこと | 範囲内を事前承認にするなら、操作を明示して頼む |
| カスタムルールは、組み込みの安全対策を無効にしない | ルールを設定しても、dot側の安全対策は残る |
| カスタムルールの選択肢は4つ(確認せずに実行/事前承認済みの場合に実行/実行前に確認/ユーザーに引き継ぎ) | 自分の記録は、確認カードの確定。4つを選ぶ設定画面の実物は、見ていない(モバイルの案内を読んだだけ) |
⑤ 依頼のファイルを大きくしすぎない
ぶるすなさん【使いどころ】dotが「依頼が無い」と言い出したのに、こちらは依頼を置いているとき。
【やること】依頼を書いたファイルの大きさを測り、900KB以下に保ちます。あふれた分は別の置き場へ移します。
【結果】10-22に依頼のファイルが1.28MBになり、GitHubのファイル取得APIが中身を空で返しました(自分の取得方法では、1MBを超えると中身が返りませんでした)。dotには、依頼が無いように見えたわけです。気づいたきっかけは、自分が見たdotの「依頼が無い」という発言でした。
【注意】受領は10-20が98本、10-21が26本、10-22が40本でした。落ち込みとファイルの大きさの関係は、日ごとには切り分けていません。
| 項目 | 数字・内容 |
|---|---|
| 依頼のファイルの大きさ(10-22) | 1.28MB |
| ファイル取得APIが中身を空で返す条件 | 1MBを超えたとき(GitHubの仕様で、取得の形式によって変わる) |
| いまの上限 | 900KB以下に保つ。あふれた分は別の置き場へ移す |
| 受領(報告の本数) | 10-20は98、10-21は26、10-22は40 |
⑥ 報告が細ったら、在庫より作成時刻の間隔を見る
りっちゃん報告が減ったら、在庫がなくなったんじゃないの?
ぶるすなさん自分もそう考えかけたよ。でも、在庫の数字は当てにならなかったんだ(②の「221本が実際は2本」)。
【使いどころ】毎日の受領数が急に減ったとき。
【やること】受領数だけでなく、Driveの作成時刻の間隔と、種類別の納品を先に見ます。
【結果】10-30の102本が、10-31と11-01は25本、11-02は35本に細りました。Driveの作成時刻はほぼ毎時1本で、候補・在庫は0本でした。気づくまで約2日かかっています。
【注意】原因の説明はdotの自己申告で、拒否の記録は確かめていません。11-03以降の回復を、送り直しの効果とは断定しません。
| 見たもの | 分かったこと | 扱い |
|---|---|---|
| 受領数 | 10-30が102本。10-31と11-01は25本、11-02は35本 | 記録 |
| Driveの作成時刻 | ほぼ毎時1本 | 記録 |
| 候補・在庫 | 0本 | 記録 |
| dotの説明① | 毎時の確認で、自分で「その回は1件」と区切っていた | dotの自己申告 |
| dotの説明② | 保存が1回止まってから「創作の承認がない」と解釈し、候補・在庫19件を保留した | dotの自己申告。拒否の記録は未確認 |
| 対処 | 承認範囲を送り直した。受領は11-03が152本、11-04が104本に戻った | 本数の回復だけ。中身の良さは言えず、送り直しが唯一の原因とも断定しない |
こっちゃん1回に1件ずつ区切って頼むのは、よくないの?
ぶるすなさん「細かく1回1件」が良いとは言えない、というのが自分の見方だよ。
1依頼の仕事を大きくして、20市・8道県・10取引所の規模で頼んだことがあります。逆に、dotの説明では、自分で1件に区切った時期に細りました。
依頼は、期限の近い順に処理させています。
⑦ 基準資料が古くないか、採用の前に正本で照らす
ぶるすなさん【使いどころ】dotに「この基準で点検して」と頼むとき。
【やること】dotが基準として引く資料を、採用する前に正本の現行版と照らします。
【結果】11-04、dotが用語基準の古い写しを基準に点検し、正しい訳を誤りと報告しました。受領後の確認でも一度採用し、配信の前に別の確認で気づいて戻しました。
【注意】この事例では、dotが古い基準資料を使っていました。受領後に確認した側も一度通しているので、確認する側の見落としも起きます。
| 段階 | 起きたこと |
|---|---|
| 1 | dotが、用語基準の古い写しを基準に点検した |
| 2 | 正しい訳を、誤りと報告した |
| 3 | 受領後の確認で、一度採用した |
| 4 | 配信の前に、別の確認で気づいて戻した |
| 決めたこと | dotが基準として引く資料は、採用する前に正本の現行版と照らす |
⑧ 採否はdotに渡さず、数字は候補の数と数え方で読む
ぶるすなさん【使いどころ】dotの報告のうち、どれを使うかを決めるとき。
【やること】採用・保留・見送りの確定は、dotにさせません。判定済みの971本(10-25時点。受領は1,023本)は、すべてdotではなく人側で確定しました。
人側とは、Claudeを統括役にした自分の側です。
【結果】10-25時点で報告の中の候補を数えると、採用は全体の31.7%、保留を除くと50.0%でした。10-25までの7日で反映と記録されたのは311件で、別の集計では、誤りの記載がある報告は16本、そのうちdotの実質の誤りは約12本でした。
【注意】採否の数字は報告本数ではなく候補の数で、報告の状態行(採用・保留・見送りの数を書いた行)に数値のある643本の合計です。全本の集計ではありません。16本のうち約4本は、誤りではない記述や、こちらの分類の過大でした。
| 指標 | 数字 | 数え方 |
|---|---|---|
| 採用・保留・見送り(候補の数) | 797・921・796 | 状態行に数値のある643本の報告の合計(候補2,514件)。全本の集計ではない |
| 採用の割合 | 31.7%(保留を除くと50.0%) | 797÷2,514/797÷(797+796) |
| 誤りの記載がある報告(10-25までの7日) | 16本(うちdotの実質の誤りは約12本) | 報告の本数で数えた。同じ7日に反映と記録されたのは311件だが、単位が違うので割合にはしない。型は、URLの404、日付や件数のずれ、公式本文で再現できない要約 |
| 11-04までの1か月の採用の割合 | 全体30%。公的指針などの原文照合に関する区分は36〜37%、素材は4% | 判定項目5,180件で数えた別の集計で、上の10-25時点の数字とは時点と範囲が違う。報告のうち反映が0の本は65% |
| 自動判定の推奨の一致 | 25本のうち24本(96%) | 10-18に採点した分。推奨と人側の確定を比べた。その後の再採点の記録はなく、確定は人側のまま |
| 「反映」の裏づけ | 30件の抜き取りで、独立に確かめられたのは3件(IDで照合)〜10件(ハッシュで照合) | 反映の件数は大半が報告に書かれた自己申告で、本番に入ったことを全部確かめた数ではない |
| 判定までの日数 | 同日783本、翌日188本、2日以上0本 | 判定済み971本の内訳。直近7日の判定565本(1日平均約81本)も、すべて人側 |
こっちゃん素材って、採用の割合が4%なのに頼むの?
ぶるすなさんだから、使う予定の行があるものだけ発注するようにしたよ。
ログイン先の取得や、規約で自動取得を禁じている提携先の取得は、そもそも依頼しません。
dotの報告を見張る役も、dot自身にはしていません。自己申告を検証できないので、別の定時タスクが見ています。
⑨ 接続とメモリは、公式の注意を先に読む
ぶるすなさん【使いどころ】外部のアプリをdotにつなぐときや、dotを作り直す・消すことを考えるとき。
【やること】公式ヘルプの注意を、つなぐ前に読みます。
【結果】公式は、接続したアプリの内容を、dotが具体的に質問されなくても自発的に確認し、メモリとして保存することがあると説明しています。接続を解除しても、取得済みの情報は削除されません。
【注意】ここは公式の説明を読んだだけで、自分では試していません。一時停止はプロフィールの「•••」から行えますが、自分は押していません。

| 項目 | 公式の説明(言い換え) |
|---|---|
| 接続したアプリ | dotが、具体的に質問されなくても自発的に確認し、メモリとして保存することがある |
| 接続の解除 | 解除しても、取得済みの情報は削除されない |
| dot独自のメモリ | 消すにはdotの削除が必要で、元に戻せない |
| クラウドブラウザー | dot独自のログインセッションで動く。自分のPCでログインしても、dotがログインしたことにはならない |
| 自分のPCへのアクセス | 任意で、初期状態はオフ |
| 間違い | dotは、設定したルールに従う場合も含めて、間違えることがある |
⑩ スケジュールを整理し、画面の提案と頼んだものを分ける
ぶるすなさん【使いどころ】スケジュールが増えて、何が動いているか分からなくなったとき。
【やること】左のスケジュール画面で「アクティブ」を開き、繰り返しと時刻を見直します。公式では、スケジュール済みのタスクを開くと、繰り返し・時刻・完了通知を変えられます。修正は、該当するタスクの中で直接行います。
【結果】自分のアクティブは3つです。Claude依頼の確認と報告(毎時)、調査作業の進捗報告(毎週18:00)、朝のClaude確認用まとめ(毎週6:50)でした。
【注意】公式によると、各タスクには独自の会話があり、dotとの会話がすべて自動で共有されるわけではありません。完了と表示されても、結果は確認します。

りっちゃんこの「Exness・XSの重要報道を監視」って、頼んだものなの?
ぶるすなさん頼んだ文ではなくて、画面が出した提案なんだ。
同じ画面には、睡眠コーチングや献立、フライトなど、一般的な提案も並んでいました。
自分の仕事に合わせた提案が混ざる理由は、確認できていません。公式は、dotがChatGPTのメモリを受け取ると書いています。

ここまでの整理:任せること・確認すること・任せないこと
ぶるすなさん10個の小ワザを3つに分けると、次の図のとおりです。強調したのは、手元に置いたものです。
仕事の量や時刻は任せますが、採否、売買の判断、ログイン先や規約で禁じる取得、dot自身による監督は任せません。

確かめていないこと
この記事は自分の運用記録と、公式ヘルプを読んだ結果で、確かめていない点があります。
効果作業時間の節約量、報告をそのまま使えた・直した・捨てた割合
原因11-03以降の回復が送り直しの効果かは、断定できません。dotが候補・在庫を保留した理由は自己申告で、拒否の記録は確かめていません
画面スマホの画面、カスタムルールの設定画面の実物(モバイルの案内を読んだだけ)
範囲画面が自分の仕事に合わせた提案を出す理由。公式ヘルプのこの記事に挙がっていないプランへの提供
よくある質問
確認待ちで止まったとき、どう対処しましたか?
範囲内の作業は事前承認にし、確認が要るものはその1件だけ止める決まりにしました。自分の記録では、会話で許可を伝えても再開せず、画面に出る確認カードを確定したあとで再開しました。
10-23・10-25・10-26(2回)の計4回、確認待ちで全体が止まった記録に基づく方法です。対策のあとで回数がどう変わったかは、記録がなく言えません。
dotの「完了」と出たら、信じていいですか?
完了の表示だけでは信じず、結果を確認します。公式ヘルプも、完了と表示されても結果を確認するよう案内しています。
自分は受領した報告をIDで突き合わせています。10-25までの7日では、誤りの記載がある報告が16本あり、そのうちdotの実質の誤りは約12本でした。
報告の量が減ったら、どうしますか?
在庫不足と決めつけず、作成時刻の間隔と種類別の納品を先に見ます。10-31〜11-02の細りでは、Driveの作成時刻がほぼ毎時1本で、候補・在庫が0本でした。
dotの説明は自己申告で、拒否の記録は確かめていません。
接続を切れば、dotの情報は消えますか?
消えません。公式ヘルプは、接続を解除しても取得済みの情報は削除されない、と説明しています。dot独自のメモリを消すには、dotの削除が必要で、元に戻せません。
ここは公式の説明を読んだだけで、自分では試していません。
どのプランで使えますか?
公式ヘルプ(2026年11月5日取得)の範囲では、EEA・スイス・英国を除く地域の18歳以上のProが対象です。Business Premiumは資格要件があり、Enterpriseは管理者が有効にするベータ版です。段階提供なので、対象でも使い始められる時期は違います。
Plusは、公式ヘルプのこの記事には挙がっていません。提供の範囲は変わることがあるので、最新は公式ヘルプで確認してください。自分はProで使っています。
売買の判断をdotに任せてもいいですか?
任せていません。自分は点検と下調べに使っていて、売買の判断はdotに渡していません。
次に読むページ
ぶるすなさんdotとは何か、対象プランと費用は、次の記事にまとめています。dotとGrok Bot・Museとの違いは、その次の記事です。


ぶるすなさん自分は、dotを点検と下調べに使っています。相場の予定を見るページは、次のとおりです。
AIに売買の判断を任せることは勧めません。判断は自分で行ってください。


