複数のAIに仕事を任せ続けるために、パーソナルアシスタントは何を覚えるべきか

AIに仕事を分けても、質問に答える人は一人

あるAIには実装を、別のAIには調査を頼む。 それぞれが仕事を進めてくれる一方で、質問や報告も別々の会話に届く。 人間はそのたびに会話を開き、何を頼んだのか、前にどう答えたのかを思い出す。 仕事を分担するAIが増えても、それを追いかける自分の時間は増えない。

筆者は、この負担を減らすために、パーソナルアシスタントの dot を窓口にして、ローカル環境の複数の Codex タスクを管理する方法を試している。 ここでいうタスクは、調査や実装など、一つの依頼について作業する会話を指す。 dot に各タスクの会話を読んでもらい、何が終わり、何が残り、何を人間に聞く必要があるかを整理してもらう。

仕組みを説明するために、三つのタスクがあるとしよう。 Aは、頼んだ機能を実装したが、同じ依頼に含まれるテストをまだ実行していない。 Bは、新しい外部サービスを使ってよいか尋ねている。 Cは、人間が「いったん止めて」と伝えた仕事である。 dot には、Aにはテストを進めるよう伝え、Bの相談を人間へ届け、Cは止めたままにしてほしい。 この三つは、以下でも使う架空の例である。

それを任せるには、各タスクの最新の報告だけでは足りない。 人間が何を頼み、なぜそう決め、その後に何を変更したかも覚えておく必要がある。 長期対話の記憶を研究した論文を読みながら、dot にどんな情報を持たせ、どう使ってもらうかを考える。

仕事が終わっても、人間への質問が減るとは限らない

Aの会話に「実装しました。次はどうしますか」と届く。 人間が毎回「最初に頼んだとおり、テストまで進めて」と答えるなら、作業の一部は任せられても、次の一歩を促す負担は残る。 アシスタントに期待するのは、以前の依頼を読み、同じ説明を求めずに仕事を進められるようにすることだ。

人間にいつ話しかけ、いつ自動で動くかは、以前から研究されてきた。 Horvitz の1999年の論文は、ユーザーが何を望んでいるか確信が持てない場合の確認や、作業中の人に話しかける負担を扱っている。 最近のやり取りを覚えておくことも、その設計原則の一つである。 答えられる質問を何度も人に戻さず、判断できない点を聞く、という dot の設計を考える手掛かりになる。

では、過去の会話を覚えていると、実際に何が変わるのか。 π-Benchは、5種類の人物設定に対して100のタスクを用意した評価である。 以前の会話で分かっている希望や、別の仕事で決まった条件を使わないと、依頼を十分にこなせない課題を含む。 最終的に仕事が完成したかと、ユーザーに不足条件を説明してもらう前にAIが気付き、解決したり尋ねたりできたかを、別々に測っている。

同論文の §4.3 では、前の会話の内容が必要な一連のタスクについて、最後のタスクだけを残し、それ以前の会話を取り除いた。 報告された3モデルの平均では、先回りして要求を解決する指標が9.5ポイント下がった一方、最終的な完成度は2.5ポイントの低下だった。 つまり、後からユーザーに教えてもらえば仕事を完成できても、何度も説明してもらう負担は減らせない場合がある。

この実験は模擬ユーザーと一つの実行構成によるもので、人間の時間が何分減るかを測ったものではない。 それでも、dot の評価で「仕事が終わったか」だけを見ていては、質問に答え続ける負担を見落とすと分かる。 同じことを聞かれた回数や、答えるために会話を読み直した回数も記録したい。

覚えてほしいのは、何を頼み、なぜそう決めたか

たとえば、Bの外部サービスを以前も検討し、データの送信先が分からないため保留したとしよう。 「外部サービスは使わない」とだけ覚えると、送信先を確認できた後も、同じ理由で止め続けるかもしれない。 「送信先を確認するまでは使わない」と、判断した理由まで残しておけば、次に何を調べればよいかが分かる。

ただ会話を保存するだけでなく、何のために使う記憶なのかを分けて考える研究がある。 CoALAは、今の作業に使う情報を置く「ワーキングメモリ」と、過去の出来事を残す「エピソード記憶」、知識を残す「意味記憶」、作業の方法を担う「手続き記憶」を整理している。 これはエージェントの設計を考えるための分類で、この名前の保存先を用意すれば性能が上がると実証したものではない。

dot に何を覚えてほしいかも、この考え方から具体的に書き出せる。 次の表は、これから整えたい記録の案である。

保存した会話を、毎回すべてAIへ渡す必要もない。 MemGPTは、AIが一度に読める入力と、その外に保存する記憶を分け、必要な情報を出し入れする構成を提案した。 dot でも、Aの次の作業を考えるときには、Aへの依頼、過去の回答、最新のテスト結果を取り出す方法が考えられる。 要約に疑問があれば元の発言へ戻れるようにしておけば、「テストまで」という一言が抜けていないかも確認できる。

古い指示や、別の仕事での回答を取り違えない

Cの仕事は止めていたが、その後に人間が「再開して」と伝えたとする。 dot が最初の停止指示だけを覚えていれば、Cはいつまでも止まったままになる。 記憶から指示を見つけるだけでなく、その後に取り消しや変更がなかったかまで読む必要がある。

LongMemEvalは、長い対話を覚えているかを五つの面から評価する。 前に出た情報を思い出す、別々の会話の内容を合わせる、出来事の前後を読む、新しい情報で覚え直す、分からないことは分からないと答える、という能力である。 dot なら、「その質問には後で回答したか」「停止指示は解除されたか」「そもそも読めていない会話がないか」を確かめる検査に使える考え方だ。 ただし論文の評価は主に質問応答であり、実際のタスクを正しく再開できるかは別に確かめる必要がある。

変更を覚えていても、それを回答に使えるとは限らない。 PersonaMemは、模擬的な長期対話でユーザーの好みが変わる場面を扱う。 論文では、好みがどう変わったかを答えられても、最新の好みに合わせた回答を作る方が難しい場合があった。 たとえば、好みが変わったと答える検査と、その人に合う提案を作る検査は、同じ結果になるとは限らない。

また、ユーザーの希望によって、使う作業手順も変わる。 2026年10月公開のプレプリントPraxisMemBenchは、ユーザーについて覚えたことと、作業手順の両方を使わなければ解けない課題を評価している。 両方を別々に保存し、作業時に検索結果を合わせる DualMem も比較し、どの希望にどの手順を使うのかという関係を、長い対話の間に保つ難しさを示した。 架空の人物と合成した履歴、隔離したアプリによる評価で、実利用者への効果はまだ別の問題である。

この問題を dot の仕事で考えると、単に「この人は外部サービスを使ってよいと言った」と覚えるだけでは危うい。 仮に、あるプロジェクトでは外部サービスを試してよく、別のプロジェクトでは録音データを外へ送ってはいけないとする。 同じユーザーの発言でも、後者に外部送信の手順を使えば間違いになる。

そのため、覚えるときには「誰が、いつ言ったか」に加え、「どのプロジェクトの、どの作業への指示か」を残したい。 指示を変更した発言も、元の指示と一緒に読めるようにする。 日付が新しいというだけで、別の仕事の条件まで書き換えないためである。

頼んだテストは進め、サービスの追加は人に聞く

冒頭のA、B、Cには、違う対応が必要になる。 Aのテストは既に頼んでいるので、dot から「残っているテストを進めて」と伝えてほしい。 Bのサービスはまだ使うと決めていないので、何に使い、どのデータを送るのかを整理して、人間に聞いてほしい。 Cは止めた仕事なので、再開の指示があるまで動かしてはいけない。

ここで大事なのは、ユーザーが好みそうな選択と、実際に頼まれた作業を分けることだ。 過去に外部サービスを選ぶことが多くても、Bのサービスを使ってよいという回答にはならない。 Aでも、テストの実行に新しい外部送信や費用が必要だと分かったなら、それまでの依頼に含まれるか確認が必要になる。

「Intelligent AI Delegation」は、仕事を任せる際には、担当を決めるだけでなく、何をしてよいかを決め、進み具合を追い、最後に結果を確かめる必要があると論じている。 dot の設計にも、この一連の仕事を取り入れたい。 これは設計を提案する論文で、dot の効果を実験したものではない。

具体的には、dot は依頼とその後の会話を読み、残っている作業が最初に頼まれたものか、「止めて」という発言がないかを確認する。 作業を実行する道具側でも、頼まれていない操作を防ぐ必要がある。 会話を読めず判断できないときは、進めてよいと推測せず、何を確認できていないかを人間へ伝える。

Bについて人間から回答が来たら、Bの会話へ返す。 その回答を、別のAやCにも使ってよいとは考えない。 「今回は試してよい」のか、「次回からも同じ条件なら試してよい」のかも残す。 こうして回答と使ってよい場面を一緒に覚えれば、次に同じ相談が来たとき、何を聞き直す必要があるかが分かる。

また、dot がAへ「テストを進めて」と送っただけで、テストが済んだことにはならない。 Aが実際にテストを実行したか、結果は成功だったかまで確認する。 人間に「終わりました」と伝えるには、指示を送った記録に加えて、作業した結果が必要である。

dot で試していることと、これから作ること

筆者の運用記録では、dot がアクセスできるタスクを一覧し、会話を読んで、進み具合と未回答の質問を整理している。 保留に見える質問にも後から回答がないかを確認する。 人間の回答を元のタスクへ返し、既に頼んだ作業が残っていれば、続きを進めるよう伝える。 人間が止めたタスクは再開しない。

ただし、画面に「待機中」とあるだけでは、仕事が終わったのか、人間の回答を待っているのかは分からない。 会話を読めないタスクについては、問題がないとも判断できない。 dot が確かめられたタスクと、確かめられなかったタスクを分けて報告する必要がある。

さらに、会話を読んで整理することと、数か月分の指示を間違えずに覚えて使うことは違う。 表1のような記録を揃え、変更前と変更後の指示を結び付け、今回の仕事に必要な情報を取り出す仕組みは、これから実装して確かめたい部分である。 現在の運用だけで、この記事の記憶の仕組みがすべて完成しているとは言えない。

情報の扱いにも確認が要る。 各タスクがローカル環境で動いていても、会話の保存やモデルへの入力まで、すべて同じ端末の中で処理されるとは限らない。 どこへ何を送るかは、実際に使う接続ごとに確かめる必要がある。

説明し直す回数が減り、任せた仕事が正しく進むか

この試みが役立つかは、人間が各タスクを直接追う場合と、dot に任せる場合を比べて確かめたい。 比べる仕事の種類と難しさを揃え、同じことを説明した回数、会話を読み直した回数、仕事が待っていた時間を記録する。 質問が減っても、必要な確認を飛ばして間違った仕事を進めたのなら成功とは言えない。

研究からは、過去の情報を探すこと、変更を覚え直すこと、覚えた情報を次の仕事に使うことを、分けて確かめる必要があると分かる。 dot では、それに加えて、頼まれた作業だけを進め、結果まで確かめられるかを検証したい。 どれだけ時間を減らせるか、何件のタスクを任せられるかについて、一般化できる測定結果はまだない。

目指しているのは、人間がBのサービスを使うかという新しい相談に集中できることだ。 既に頼んだAのテストを始めるために、同じ指示を繰り返す必要は減らしたい。 Cについても、止めたことを毎回念押しせずに済ませたい。 そのために dot には、頼んだ内容だけでなく、その理由と後から変えた指示まで覚えていてほしい。