別々のChatGPTプロジェクトから同じINBOXへ3件登録できた――「たす」の横断テスト

「たす」。2026年10月4日、僕はこの短い言葉を使い、別々のChatGPTの会話で出た仕事のアイデアを、一つの受信箱へ集められるか試しました。

業務シートを確認すると、登録日時が13時24分、13時31分、13時34分の3件が、同じ「02_INBOX」というタブに別々の行として記録されていました。異なる会話の内容が、一つの保存先に並んでいたのです。

ただし、これは複数のAIが同じ会話を記憶するようになった、という話ではありません。会話をまたいで、同じ外部のデータへ情報を残せるか。その具体的な結果と限界を整理します。

「たす」は、思いついた内容を受信箱へ残す合図です

僕は複数の仕事を、ChatGPTのプロジェクトやスレッドに分けて進めていました。自分のWebサイトの改善、EC事業の分析、AIを使った記事制作など、扱う内容はそれぞれ違います。

そこで、会話の中で「あとで仕事として扱いたい」と思った内容を、その場で長いタスク表に書き直さずに残す方法を作りました。「たす」は、その直前の依頼や話題をタスク候補として保存するために使った短い合図です。

受け皿にしたのは、Googleスプレッドシートに作った「02_INBOX」というタブです。ここでいうINBOXは、仕事の依頼やアイデアをいったん受け取る「受信箱」のことです。

登録のルールと、実際の記録は外部に置きました

複数のチャットに同じ情報を渡すには、どこへ何を保存するかという共通の決まりが必要です。僕はそれを「AI業務OS｜タスク登録・運用ルール」というGoogleドキュメントに整理しました。

実際の記録は別のGoogleスプレッドシート「AI業務オペレーション｜News to Action」へ保存します。受信箱の02_INBOXには、元の依頼であるRaw Memo、AIによる仕事の解釈、どのプロジェクトから来たのか、状態などを分けて記録できます。

この設計なら、同じ仕事に関わる情報を、一つの会話の記憶だけに閉じ込める必要はありません。ただし、ルール文書が存在することと、それぞれのAIが毎回全文を正しく読み取ったことは、別の確認です。

ルール文書の版が変わった場合に何を確認するかは、AI業務ルールを読み直すとVERSIONが違った記録で、別の実例として整理しています。

一件目は、Webサイトの修正計画でした

最初の記録は、10月4日の13時24分に、僕自身のWebサイト運用に関するChatGPTプロジェクトから登録されたものです。ページ内の導線をどう修正するか、優先度と工程順を整理したいという依頼でした。

この内容は、共通INBOXの一行へ保存されました。元の発言、対象プロジェクト、AIの解釈が別の欄に記録され、登録を識別するCapture IDも付いていました。

ここで確認できるのは、修正計画についての依頼を保存できたことです。Webページが実際に編集され、公開されたという結果ではありません。

二件目と三件目は、別のプロジェクトとスレッドから届きました

13時31分には、別のEC運用プロジェクトから、生成AIに対応した商品ページの改善案を精査したいという依頼が保存されました。

さらに13時34分には、Webサイトの記事制作に関する別スレッドから、ChatGPTのWork機能でWordPress記事を編集できるか調べたいという相談が登録されました。

この二件も、一件目と同じ02_INBOXへ別行として保存され、異なるCapture IDが付いていました。内容も対象プロジェクトも違う三件が、共通の受信箱に集まったことを確認できました。

ただし、どの依頼も登録しただけで外部サイトの編集まで実施されたわけではありません。記事編集の可否調査と、実際にログインして保存・公開する作業は分ける必要があります。

三件の登録結果を確認し、横断テストを完了しました

採掘記録では、最初の一件が保存された後、別のプロジェクトやスレッドから二件が追加され、合計三件が共通INBOXに存在することを確認しています。

その後、横断テストを管理する別のタスクはDONE、阻害要因を示すBlockerはNONEとして記録されました。当時のHOME画面では、未整理のINBOXが三件あることも表示されていました。

これは「三件を受信できた」という試験についての完了です。受信した三件それぞれについて、依頼された調査やサイト変更がすべて完了した、という意味ではありません。

AIの完了報告と、保存先に本当に記録されたことの違いは、AIに外部サービスを操作させるときの確認段階でも扱っています。

登録時と今とでは、同じ行の状態が変わっています

この記事を制作する2026年10月10日に、当時の三件のCapture IDを使って正本シートを再検索すると、いずれも同じ02_INBOXに存在しました。

ただし、現在の三件の状態はCAPTUREDではなくPROMOTEDでした。受け取ったままの候補から、正式タスクへ整理された状態に進んでいることが、現在のシートから分かります。

一方、何日に誰が各行を正式タスクへ整理したのか、その後すべての仕事が終わったのかまでは、今回の読み取りだけでは確定できません。過去の登録時点と現在の記録を混同しないようにします。

三件の保存成功は、すべてのAIの内部動作を証明しません

今回の試行で確かめたのは、別々のChatGPTプロジェクトやスレッドからの入力が、共通のシートへ三件保存されたことです。

しかし、それぞれのAIが登録前に最新の運用ルール全文を読み直したか、どの経路で正確な保存先を選んだかは、三件の行が存在することだけでは完全に分かりません。複数アカウントや別のAI製品を使って同じ結果が出ることも、今回の三件では検証していません。

また、dotという継続的に仕事を扱うAIアシスタントを中心に据える構想はありましたが、三件の登録結果からdotによる長期間の自動運用が保証されたわけではありません。

作業の現在地を別の会話へ引き継ぐ際の考え方は、AI作業を引き継ぐとき、成果物だけでなく「作業状態」を渡すが参考になります。

この三件から分かったのは、会話の外に共通の受け皿を持つ意味でした

僕が試していたのは、ChatGPTの記憶を増やしてすべての仕事を覚えさせる方法ではありません。別々の会話で生まれたアイデアを、あとから同じ場所で確かめられるようにする方法です。

2026年10月4日の三件については、共通INBOXへの登録が実際に成立しました。登録ID、元の内容、出どころ、後から変化した状態を、同じ保存先で追えることも確認できました。

今回の再利用できる知は、AIに共有してほしいのが「会話の記憶」なのか「仕事の記録」なのかを分けることです。共通のルールと保存先を外部に置き、保存結果を一件ずつ検証すれば、少なくとも今回のように異なる会話から同じ仕事の受信箱へ記録を集められます。

このKnowledgeの関連知識

短い合図で依頼する：「続きを書いてください」で進む承認型ワークフロー。短い指示が機能するために、実行対象と現在地を共有する条件を扱います。

dotでの運用を振り返る：dotを使い始めた3日間のKnowledge運用記録。複数のAI作業を継続運用するとき、何ができたかを別の試行から確かめられます。