「ニュースは17時、dotは19時」――AIが時刻変更の対象を取り違えた記録

「違う。ニュースを記入するのは17時。dotは19時のままでいい」。2026年10月4日、僕はAIが示した時刻変更の案に、こう訂正を入れました。

僕が変更したかったのは、ニュースの会話からKnowledgeやBlogのネタを拾う仕事だけです。ところがAIは、別に動かしていたdotの共通処理まで17時へ変更する話だと受け取っていました。同じ「19時」という数字が二つの仕事に出てきたため、変更対象が混ざってしまったのです。

このとき起きたのは、AIの説明や予定変更案の取り違えです。dotの設定が実際に誤変更され、その結果別の処理が動いたという記録はありません。僕が何を訂正し、その後どこまで確認できたのかを整理します。

同時に管理していたのは、目的の違う二つの定期処理でした

一つはニュース採掘です。日々のニュースを集めた会話から、Knowledgeにできる事実や試行錯誤、Blogで深掘りできる話題を拾い、専用のGoogleスプレッドシートへ整理して保存する仕事でした。

もう一つは、複数のプロジェクトをまたぐ業務を確認するdotの共通運用です。dotはChatGPT内のAIアシスタントで、Googleドキュメントの運用ルールや業務シートを読み、未処理タスクなどを確認する役割として設計していました。

ニュースの素材を採掘する仕事と、共通業務シートを巡回する仕事では、対象も目的も違います。実行する時刻が同じだったとしても、一方の変更をもう一方へ自動的に広げる理由にはなりません。

最初の19時は、ニュース採掘への依頼でした

当初、僕はニュースの会話を自動で採掘し、ネタ帳に保存する作業について「これを、自動化したい。先程のタスクシートに記入して、毎日夜19時に実行するようにしたい」と依頼していました。

その後、ニュース採掘の時刻を19時から17時へ変えるよう伝えました。しかし短い変更指示だけを見ると、「19時」がどの処理の設定を指しているか、文脈を正確にたどる必要があります。

僕の意図では、ニュース採掘だけが17時で、dotの共通運用は従来の19時を維持するものでした。

AIは、dotの共通時刻まで動かす案を出しました

採掘記録によると、AIは一度、dotの共通起動も「08:00・13:00・17:00」にそろえるという趣旨で解釈しました。変更するつもりのなかった共通運用まで、ニュース採掘の時刻変更に巻き込んだわけです。

ここで僕は「違う。ニュースを記入するのは17時。dotは19時のままでいい」と明確に訂正しました。時刻だけを言い直したのではなく、変更する仕事と変更しない仕事を同時に指定しています。

この段階で確認できた失敗は、AIが依頼の対象範囲を取り違えたことです。誤った設定が外部で保存されたことや、dotが17時に動いてしまったことを示す記録ではありません。

短い承認や変更指示が成り立つ条件については、「続きを書いてください」だけでAI作業を進める承認型ワークフローでも、作業対象と現在地を共有する必要性を扱っています。

元の19時の依頼は消さず、AIが理解した内容を直しました

この訂正では、Googleスプレッドシートの受信箱「02_INBOX」に保存した元の発言を残し、AIが読み取った仕事内容を別欄で修正しました。

「Raw Memo（原文）」欄には、最初の「毎日夜19時に実行する」という依頼が残っています。一方、「AI Interpretation（AIの解釈）」欄では、ニュース採掘は17時、dotの19時の共通運用は変更しない、という訂正後の意味へ書き換えられました。

これは元の発言を17時に書き換えたということではありません。後で経緯を確認したときに、「本人が最初に何と言ったか」と「訂正を受けた現在の解釈」が同じ文章に混ざらないようにするための記録方法です。

実際にこの区別が保存されたことは、当時の採掘記録に加え、今回の正本Sheetの該当行を読み直して確認できました。なお、その行には後日追加された運用上の変更も記録されているため、当日の17時設定を現在もそのまま稼働している設定とは扱いません。

17時の自動化が登録されても、実行できたとは限りません

採掘メモには、ニュース採掘用の17時の定期処理を別に作成し、設定が有効になったという記録もあります。作成時の指定は日本時間の毎日17時でした。

しかし、その時点では初回の実行結果を確認できていませんでした。設定を登録できたことと、指定時刻にニュースの会話が取得され、採掘結果がスプレッドシートへ保存されたことは別の確認です。

定期タスクの最初の作成時には接続要求で停止し、再試行で設定だけが完成しました。作成と実行の確認を分けた詳細は、AIの定期タスクは、作成できたら実行も確認できたことになるのかで扱っています。

今回の中心は変更対象の訂正ですが、外部操作についても、AIの説明、設定が保存された状態、実際の実行を同じ「完了」にまとめないことが必要でした。

外部サービスの操作状態の分け方は、AIに外部サービスを操作させるとき「送信した・保存された・表示された」を分けて確認するでも具体的に整理しています。

次に同じ変更を頼むなら、対象と維持条件を一緒に書きます

今回の出来事から再利用できるのは、「17時」といった数字だけで設定変更の範囲を決めない方法です。変更する処理の名前、変更前後の時刻、変更しない処理をそろえて伝えます。

この事例なら、「ニュース会話からKnowledge・Blog候補を採掘する処理だけを、毎日19時から17時へ変更。dotの共通確認は19時のまま維持」といった指定になります。これは今回の経緯を説明するための書き方の例で、当時の本人発言をそのまま引用した文章ではありません。

AI側も変更を実行する前に、ニュース採掘とdotの共通確認を別の処理として理解しているか確認できます。設定が保存されたかどうかは、その後の読み戻しで判定します。

今回の訂正で確認できたこと

2026年10月4日の記録では、AIがニュース採掘とdot共通運用の時刻を混同し、本人から訂正を受けました。その後、受信箱では元の19時の依頼を保持しながら、ニュース採掘だけ17時とする解釈に整理できました。

ただし、外部のdot共通時刻を誤変更したという事実は確認されていません。また、当時作成した17時の専用処理が実際に採掘と書き込みまで成功したことも、その時点では検証できていませんでした。

僕がこの事例から残したいのは、時刻を正しく伝えることだけではありません。AIに複数の仕事を任せるなら、「何を変えるか」と同じくらい「何を変えないか」を明示し、本人の指示・AIの解釈・外部設定・実行結果を別々に確認するということです。

このKnowledgeの関連知識

短い指示の前提：「続きを書いてください」だけでAI作業を進める承認型ワークフロー。短い言葉で作業を進めるために、対象と現在地を共有する方法です。

保存と実行の確認：AIに外部サービスを操作させるとき「送信した・保存された・表示された」を分けて確認する。AIの完了報告と外部の実際の状態を分ける方法です。

dotの実務運用例：ChatGPTのdotをローンチ直後から3日間使った記録。dotに任せる仕事の役割と確認工程がどのように変わったかを扱います。