チャットの引っ越しまでAIがやってくれた――dotを見て考え始めた、これからのコンテキスト管理
dotの動きを見て、CodexとWorkに新しいチャットへの引き継ぎを試しました。引っ越しは成功。一方でKnowledge OSへの保存は、以前に一度通った後も安定せず、AIに任せる操作と人が確認する判断を考えました。
ここ数日、ChatGPTを使っていて、思いがけない発見が続いています。先日、Workを新しく開いたところ、まだ何も頼んでいないのに、当社の仕事に関する具体的な提案が表示されていました。社員への技術指導の内容が成果物に反映されていないのではないかという指摘や、メールに届いた予定についての確認です。この体験は、以前の記事に記録しました。
それだけでも十分驚いたのですが、その後、別のことを考えるようになりました。
これからは、AIとの会話を次のチャットへ渡す操作まで、人間が毎回行わなくてもよいのではないか。
今回は、そんなことを考えるきっかけになった体験を残しておこうと思います。
チャットが長くなったら、どうしていたか
私は日常的にChatGPTを使っています。単発の質問だけでなく、会社の経営やDX、技術的な検討、業務改善などについて、何日にもわたって相談することもあります。そうなると、どうしても一つのチャットが長くなります。
以前は、AIに会話の内容をまとめてもらい、その文章をコピーして、新しいチャットに貼り付けていました。引き継ぎたい内容が多ければ、Markdownファイルとして残しておくこともあります。ここでいうコンテキストは、次の仕事を進めるためにAIが参照する、これまでの経緯や条件のことです。
現在はChatGPTのProjectも利用しています。当社では、会社の方針や経営判断を整理したCompany OS、日々の会話や業務から得た経験を蓄積するKnowledge OSなども整備してきました。それらをMarkdownとして管理し、必要に応じて更新しています。
この方法は、今でも有効だと思っています。ただ、考えてみれば少し不思議なことでもあります。AIに仕事を手伝ってもらうために、人間がAIへ渡す情報を整理し、保存し、次のチャットに持っていく。AIを使い続けるための管理作業を、人間が引き受けていたわけです。
dotを見て、引っ越しも任せられないかと思った
こうした考えが変わり始めたきっかけは、dotという、会話の外でも継続的な仕事を支援するChatGPTのAIアシスタントでした。
最近、dotが過去の文脈を踏まえて仕事を提案したり、複数のWorkを動かしたりする様子を見る機会がありました。こちらが一つひとつ手順を指示しなくても、AIが仕事を分け、別の作業へつなげていく。
その様子を見ていて、ふと思ったのです。
だったら、チャットの引っ越しだってAIに任せられるのではないか。
私が新しいチャットを作り、引き継ぎ文章をコピーして貼り付ける。これまで当たり前のように行っていた作業ですが、AIが別の仕事を立ち上げられるのであれば、同じようなことができても不思議ではありません。
もっとも、最初から具体的な方法が分かっていたわけではありません。dotの動きを見ていて、できそうな気がした。それが出発点でした。
CodexとWorkで、新しいチャットへの引き継ぎを試した
そこでCodexに、新しいチャットを作成し、現在の作業を引き継ぐ内容を入力できないか頼んでみました。すると、独立したチャットが作られ、引き継ぎ用のメッセージが入力されていました。自分でコピーして貼り付けたわけではありません。
さらにWorkでも同様のことを試しました。最初はうまく切り替わりませんでしたが、再試行では新しいチャットの作成、引き継ぎ内容の自動投入、その先での応答まで確認できました。新しいチャットには、「ChatGPTが別のタスクから送信」という表示もありました。
この試行の詳しい経過は、ProjectとLocal Workのエラーを記録した記事の「2026年10月10日追記」に書いています。ここで重要なのは、引き継ぎを自動で行う操作が、私の環境では実際に通ったことです。
ただし、元の長い会話がすべて正確に伝わったか、長期間の運用でも同じように動くか、内部でどの機能が処理したかまでは確認できていません。成功したのは、新しいチャットを作り、必要な引き継ぎメッセージを渡し、そこで応答を受けるところまでです。
それでも、人間が新しいチャットを開いて文章を貼り付けるという操作を、AIが実際に代わってくれたことには意味を感じました。
では、Markdownの整理もAIに任せられるのか
この体験から、さらに考えが広がりました。私自身、会社の情報をMarkdownで管理しています。しかし、そもそも、その管理作業の一部もAIに任せられないでしょうか。
例えば、会話の中で重要な判断が出てきたとします。そのとき私が、
これ、Knowledgeに入れておいて。
と頼む。するとAIが、残すべき内容を整理し、既存の記録と重複していないか確認し、候補として適切な場所へ保存する。新しい仕事を始めるときには、過去の情報から必要なものを探し、現在の条件に合わせて読み直す。チャットが長くなれば、作業の状態を整理し、新しいチャットに引き継ぐ。
そうなれば、人間が毎回ファイルを開き、文章をコピーし、保存場所を考える作業は少なくなります。
もちろん、これはまだ構想です。チャットの引っ越しが成功したからといって、Knowledgeの分類や更新まで自動で正確に行えることが証明されたわけではありません。ただ、今まで人間の仕事だと考えていた操作の一部を、AIに任せられる可能性を感じています。
一度できたKnowledge保存も、まだ安定していない
当社では、ChatGPTとの会話からKnowledge OSへ記録を残す仕組みも作っています。9月には、通常のChatから会話カードの候補をMarkdownとして保存し、PC側のKnowledge Managerによる正式登録まで、一度通して確認できました。
ただし、その一度の成功で、PCでもスマートフォンでも、いつでも同じように使える状態になったわけではありません。その後の試行では、専用のSkillやGoogle Driveとの接続を使っても、実際のMarkdownファイルの保存と、保存した内容の読み戻しまで完了できない場合がありました。
ちょうど検証していた時期には、OpenAIもプラグインの管理や表示に関する障害を公表していました。ただし、今回の保存失敗がその障害によるものだったのか、Skillの実装や接続設定によるものだったのかは、まだ分かっていません。
興味深かったのは、作業を担当していたWorkが、問題を整理し、当面の代替手段を提案し、後日あらためて確認する予定まで設定したことです。Knowledgeへの保存そのものは、この試行では成功していません。しかし、解決できなかった仕事をその場で終わりにせず、次の確認につなげるところまでAIに任せられました。
「保存した」という返事だけでは完了とは言えません。目的の場所に、目的の形式で残り、内容を読み戻せるか。以前の記事で得たこの確認の仕方は、今回の失敗を見分けるときにも必要でした。
情報管理の判断まで不要になるわけではない
ここまで考えると、情報管理アプリやChatGPTのProjectすら不要になるのではないか、という気もしてきます。ただ、私はまだそこまで結論を出していません。
当社の場合、Company OSには会社としての方針や判断があります。Knowledge OSには、実務の経験、試行錯誤、判断に至った理由などが蓄積されています。さらに、正式な業務成果物の原本はNASで管理しています。これらは、AIとの会話を引き継ぐためだけに存在しているものではありません。
会社として何を決めたのか。どの資料が正式な原本なのか。何が確認済みで、何がまだ仮説なのか。その区別は、AIが進化しても必要です。
特に土木設計の仕事では、AIが過去の資料を見つけたからといって、それが現在の設計条件に適用できるとは限りません。資料の版や更新日、今回の条件、元請会社から受けた指示や確認事項まで確かめる必要があります。
だから、管理する情報の構造や、人間が判断する仕組みまで不要になるとは考えていません。変わるかもしれないのは、情報を整理し、候補として保存し、次の仕事へ渡す操作を、誰が担当するかという部分です。
AIに操作を任せ、人は結果と判断を確かめる
振り返ってみると、私のAIの使い方も少しずつ変わってきました。最初は質問して回答をもらうことが中心でした。その後、資料の整理やプログラムの作成、業務の検証を頼むようになり、WorkやCodexで複数の工程をまとめて任せるようになりました。
dotの動きを見て、AIが自分から仕事を見つけたり、別の作業につなげたりすることに驚いた。今回、チャットの自動引っ越しを試したのも、その延長にあります。
これまでは、人間がAIのためにコンテキストを整理し、次のチャットへ渡していた。これからは、その操作もAIに任せられるかもしれない。
ただし、AIが保存した内容や、引き継いだ情報が正しいかを確かめる仕組みは必要です。会話カードの候補を残すことと、会社の正式な方針や知識へ反映することも別です。設計上の判断までAIが勝手に確定してよいわけではありません。AIに任せる操作が増えるほど、人間が確認すべきことを明確にする必要があります。
まだ完成していないからこそ、試してみたい
今回の体験で、コンテキスト管理の完成形が見えたわけではありません。新しいチャットへの引っ越しは成功しました。一方で、Knowledgeへの保存は、以前に一度通った後も安定していません。引き継ぎ先が必要な情報をどこまで正確に理解するのか、保存した内容を次の仕事で適切に利用できるのかも、これから確かめる必要があります。
今回の発想は、最初から自動引っ越しの仕組みを作ろうとして生まれたものではありません。dotが仕事を進める様子を見ていて、何となく「これもできるのではないか」と考えた。そして、試してみたら実際にできた。この順番が、私には重要でした。
AIの機能を一つ覚えたというより、AIに任せられる仕事の範囲について、自分の中にあった前提が変わったように感じたからです。
当社では、コードを書けないところから、AIと相談しながら小さな仕組みを作り、少しずつ会社の業務へ取り入れてきました。今回も、その延長にあるのだと思います。できるかどうか分からなくても、まず試す。できたことと、まだできないことを分けて記録する。そして、日々の仕事の中で使える形へ近づけていく。
AIが多くの作業を引き受けるようになったとき、人間がどこまで情報を管理し、どこからAIに操作を任せられるのか。今はまだ答えが出ていません。ただ、少し前まで当たり前だと思っていたチャットの引っ越しを、今回はAIがやってくれました。それだけでも、これからの仕事の進め方を考え直すには、十分な出来事だったと思います。
※この記事は2026年10月10日時点の利用体験と考察です。新規チャットの作成・引き継ぎは私の環境で確認したもので、すべての利用環境で同様に動くことを保証するものではありません。Knowledgeへの自動保存は引き続き検証中です。