常時稼働のパーソナルエージェントは、文法が上手になっただけの通知フィードのように振る舞うべきではありません。新しいメール、課題、価格の変動、ドキュメントの編集、カレンダーの更新のひとつひとつに目に見える反応をすることが仕事ではありません。仕事は、あなたが別のことをしている間に見張りを続け、次にすべきことを変えるわずかな変化を見分け、ふさわしい仕事をふさわしいタイミングと段階で再び表に出すことです。
ですから「エージェントはいつ起きるべきか？」は、単なる性能の問題ではなく設計の問題です。起きる回数が多すぎれば、エージェントは新たな雑音の源になります。静かにしすぎれば、そもそも見張りを頼んだ理由を見逃します。明確な境界なしに行動すれば、役に立つはずのバックグラウンドのシステムが権限の問題に変わります。
正しい答えは、一連の判断です。新しいイベントは、何の反応も要らないこともあれば、あとで確認すればよいこともあり、メインのエージェントが一手間かけるべきこともあれば、あなた自身の判断が必要なこともあります。これらは別々の結果であり、信頼できるエージェントはそれらをひとつにまとめてしまうべきではありません。
常時稼働が表すべきは連続性であって、割り込みではない
「常時稼働」に価値があるのは、世界がチャットのセッション単位で動いてくれないからです。ノートパソコンを閉じたあとにプルリクエストが失敗することがあります。会議中に取引先が納期を変えることもあります。最後に話し合ってから 3 日後に契約が署名されることもあります。継続的な責任を担うのであれば、エージェントはこうした空白をまたいで連続性を保つ必要があります。
連続性に、絶え間ない推論は要りません。ほとんどのイベントは、重複、型どおりの確認、関係のない変更、あるいはあとでも十分に役立つ情報です。イベントごとに大きなモデルを起こせば計算資源を無駄にしますが、より大きなコストは振る舞いの面にあります。起きるたびにメッセージになるなら、エージェントはユーザーの注意をまるでただであるかのように使ってしまいます。
職場の通知に関する研究は、同じ緊張関係を以前から見いだしています。人は受け身で状況を把握できることを大切にする一方で、通知はいま集中している作業を妨げます。上限付きの延期に関する研究も、「今すぐか、まったく知らせないか」が誤った二択である理由を示しています。通知は決まった上限の範囲内で遅らせることができ、そうすれば届くたびに緊急として扱わなくても、状況の把握は保たれます。
したがって、常時稼働のエージェントは 3 つの時計を分けて扱うべきです。
イベントが届く時刻
エージェントがそれについて推論する必要がある時刻
ユーザーが知る、あるいは判断する必要がある時刻
3 つすべてが「今すぐ」のこともあります。しかし、たいていはそうではありません。
起きることは通知ではなく、通知は許可ではない
いちばん大事な境界は、見落としやすいものです。イベントを検知すること、メインのエージェントを起こすこと、ユーザーに知らせること、外部に向けて行動することは、4 つの別々の段階です。
Comma があるプルリクエストを追っているとしましょう。新しいレビューコメントが届きます。見張りのプロセスはまず、そのコメントが関係のある何かを変えるかどうかを判断できます。変えるなら、メインのエージェントが起きて、プルリクエスト、周辺の議論、それが属する Task を確認できます。エージェントは、あなたの手を止めずに下書きを更新したり、修正を用意したりできるかもしれません。マージの期限が危ういことを伝える必要があるかもしれません。あるいは、セキュリティ上のトレードオフを受け入れるかどうかのような、あなたに属する判断に行き着くかもしれません。
どの結論も、コメントが届いたという事実だけからは導けません。
Comma のアーキテクチャは、この分離に沿って動くよう設計されています。軽量な Loop が見張りを続け、必要なときだけメインのエージェントを起こします。そのあと、文脈が必要な仕事はメインのエージェントが担います。Loop がどのようにイベントをふるいにかけ、起こす処理の重複を除き、上限の範囲で動くかといった技術的な詳細は、分散エージェントハーネスのためのプログラマブルなイベントループ で扱っています。読み手にとっての原則はもっと単純です。イベントは証拠であって指示ではなく、起きることは調べてほしいという依頼であって行動の許可ではありません。
メインのエージェントを起こすための 4 つのテスト
役に立つ起こし方の方針は、4 つのテストとして表せます。合計点が高ければ自動的に通る採点表ではありません。テストごとに、別の種類の誤報を取り除きます。
1. 実質的な変化はあったか？
最初のテストが見るのは活動ではなく状態です。新しいメッセージは活動です。期限が早まる、障害が現れる、承認が届く、約束された条件が満たされる、といったことが状態の変化です。
新しいイベントがすでに知っていることの繰り返しであったり、計画を変えずにメッセージを受け取ったと伝えるだけであったり、見張るよう頼まれた責任の外にあったりするなら、エージェントは静かにしているべきです。安定した識別子と重複の除去はシステムの面で役立ちますが、意味の上での重複にはやはり判断が要ります。別々の 2 通のメッセージが、同じ「変化なし」を伝えていることもあるからです。
このテストは、動きが進捗のふりをするのを防ぎます。
2. その変化は進行中の目標や制約に影響するか？
何が実質的かは、人によって違います。航空券の値下がりは、それだけでは重要ではありません。まだ行くつもりの旅行について、ユーザーが示した予算を下回ったときに意味を持ちます。ビルドの失敗も、放置されたブランチ、試験的なブランチ、リリース候補のどれで起きたかによって意味が変わります。
エージェントには、目標、いまの計画、関係する制約、そしてそれらの事実がどこから来たのかがわかるだけの出どころの情報が必要です。この文脈がなければ、「重要」は具体的に役立つことではなく、一般に派手なことを指しがちになります。
範囲が信頼を守るのも、ここです。あるリポジトリを追う Loop は、そこで他のプロジェクトに軽く触れられたからといって、それを新しい任務にすべきではありません。届いた内容は、見張っている責任に情報を与えることはできますが、その責任を黙って広げることはできません。
3. 行動できる時間枠はあるか？
大事ではあっても、今すぐ推論しなくてよい変化もあります。金曜日に確認されるレポートは、まとめの中で待たせておけます。配送の遅れは、それに依存する予定を脅かすときになって初めて関係してくるかもしれません。反対に、会議のキャンセルで貴重な予約枠が空いた場合や、本番環境の不具合がより多くのユーザーに広がっている場合は、1 分遅れるごとに価値が失われていきます。
問いは単に「これは緊急か？」ではありません。今推論すれば、あとで推論するより良い選択肢が生まれるか？ です。
答えがイエスなら、メインのエージェントを起こします。その情報があとでも同じように行動に使えるなら、自然な区切りまで延ばすか、関連する更新とまとめます。とれる行動がなく、計画も変わらないなら、記録して静かにしています。
4. 次の判断は誰のものか？
メインのエージェントは文脈を集めたあと、次の一歩を決める権限が誰にあるかを見極めるべきです。
ユーザーの指示の範囲内にある、型どおりで取り消しのきく仕事は、たいてい誰の手も止めずに続けられます。エージェントは Task のメモを更新したり、比較表を用意したり、返信の下書きを書いたりできます。結果を伴う判断、あいまいな判断、好みに左右される判断は、ユーザーに戻すべきです。Comma では、人の判断が必要な仕事は、推測で押し進めたり完了扱いにしたりせず、要確認 で待たせることができます。
良いエスカレーションは具体的です。何が変わったか、なぜそれが計画を変えるのか、エージェントがすでに何を確かめたか、どんな判断が必要か、その判断がいつ役に立たなくなるかを伝えるべきです。「どうしますか？」は引き継ぎではなく、終わっていない分析です。
起きるか寝るかではなく、正当な結果は 4 つ
テストを当てはめると、エージェントには 4 つの役に立つ応じ方があります。
静かにしている。 関係のある変化がない、イベントが重複している、あるいは見張りの範囲外にある場合です。静かにしていることは、何も処理しなかった結果ではなく、誤りを調べられるだけの内部の記録を残したうえでの意図的な結論であるべきです。
延ばす、またはまとめる。 変化は関係があるものの、その価値が遅れても損なわれない場合です。次の Task の区切り、ブリーフィング、短いまとめに加えます。延期には境界が必要です。「あとで」は、誰も担当しない積み残しではなく、決まった時刻や条件を指すべきです。
メインのエージェントを起こす。 イベントが計画を変えうる場合、より広い文脈を必要とする場合、あるいは軽量なフィルターには不確かすぎる場合です。最終的な結果が静かにしていることだとしても、起こすのは適切です。メインのエージェントは調べたうえで、ユーザー向けのメッセージは要らないと結論づけるかもしれません。
ユーザーに主導権を戻す。 エージェントが、権限、リスク、好み、あるいはユーザーにしかできないトレードオフを含む判断に行き着いた場合です。すでにした仕事を残したまま、進行を再開させるための最小限の判断を示すべきです。
この 4 通りのモデルによって、不確かさを扱えるようになります。見張りのプロセスは、根拠が弱いときに自信があるふりをしなくて済みます。メインのエージェントを起こして、より深く確かめさせればよいのです。メインのエージェントもまた、判断がユーザーに属するときに、無理に自律を演じる必要はありません。
確信度が変えるべきは経路であって、イベントを隠すことではない
常時稼働のシステムは、ときに間違えます。危険な失敗は、単なる誤報ではありません。自信をもって握りつぶされ、ユーザーが取り戻す機会を一度も得られないイベントです。
Comma の初期設定の姿勢は、この非対称性を反映しています。Loop が Jev を使って、追っているプルリクエスト、課題、スレッドをふるいにかけるとき、「静かにする」には高い確信度が必要です。不確かな場合やエラーはメインのエージェントに回り、メインのエージェントはユーザーに書く前に元の情報を確かめるよう指示されています。Jev は分類はできますが、メッセージを送ること、外部の状態を変えること、自分にさらにアクセスを与えることはできません。現在の動作と制限は、Comma のエージェントハーネス Salix のご紹介 と Loop のドキュメント に記載されています。
この設計で間違いがなくなるわけではありません。自信をもって誤った「静かにする」判断が、更新を隠してしまうこともありえます。それでも、不確かさをより安全な経路に乗せることはできます。黙って切り捨てるのではなく、より深く調べる経路です。ユーザーは見張りを一時停止したり削除したり、範囲を狭めたり、操作の権限を取り戻したりできるべきでもあります。エージェントがバックグラウンドにいることを許されるのは、その存在を確かめられ、取り消せるようにしてこそです。
良い割り込みは、仕事を済ませてから届く
常時稼働のパーソナルエージェントの価値は、あなたより早く気づくことではありません。それなら監視ツールがすでにやっています。価値は、変化を進行中の責任に結びつけ、あなたに必要な作業を減らせることにあります。
役に立つ割り込みは、中身としてはたとえば次のようなものです。
レビュアーから認証フローの変更を求められました。これは、あなたが木曜日に設定したリリース条件を満たす妨げになります。現在のブランチを確認し、指摘された問題を再現しました。パッチとテストは用意してあります。適用する前に必要なのは、互換性のトレードオフを承認するかどうかの判断だけです。
このメッセージには、文脈、影響、済ませた調査、提案する次の一歩、そして明確な判断の境界が含まれています。そのイベントがなぜ重要なのかを、ユーザーに組み立て直させることはありません。もっともらしい次の行動を、それを実行する許可と取り違えることもありません。
エージェントが割り込まないと決めたときにも、同じ基準が当てはまります。延ばした更新は、約束した区切りで再び現れるべきです。静かにするという判断は、あとから検証できるべきです。判断が必要な Task は、終わりのない会話の中に消えるのではなく、目に見える形で待つべきです。
目指すのは落ち着いた連続性
常時稼働のエージェントは、絶え間ない注意を求めることなく連続性を生み出すべきです。外側のシステムは、安く、狭く見張ります。メインのエージェントは、変化が計画を変えうるときに起きます。割り込む前に調べます。ユーザーがすでに権限を与えている型どおりで取り消しのきく仕事は続け、結果を伴う選択は関係する仕事を添えて戻します。
その結果として得られるのは、よくしゃべるエージェントではありません。静かにしながら責任を保ち続け、静けさがもう役に立たなくなる瞬間を正確に知っているエージェントです。
よくある質問
メインのエージェントが起きる前に、何が動いていますか？
Comma では、軽量な Loop が、選んだ受信箱、リポジトリ、フィード、API、webhook を見張ります。そのプログラムは決まったルールを当てはめることができ、Jev に型付きの判断をすばやく求めることもできます。メインのエージェントとその大きな文脈が動くのは、Loop がより深い調査や行動のために起こしたときだけです。
エージェントが起きるたびに、ユーザーへの通知にすべきですか？
いいえ。起きることで、メインのエージェントは文脈を確認し、そのイベントが何を変えるかを判断できます。バックグラウンドの仕事を続けることも、更新を延ばすことも、ユーザーの手を止める必要はないと結論づけることもできます。ユーザーの注意を求めるのは、状況の把握や判断に時間の制約があるときだけにすべきです。
エージェントが確信を持てないときは、どうすべきですか？
不確かなときは、イベントをより能力の高い判断者に回すべきです。軽量なフィルターはメインのエージェントを起こせます。メインのエージェントは元の情報を確かめ、文脈を集め、自分の権限の範囲で進めるか、ユーザーに尋ねるかを選べます。不確かさを、自信のある「静かにする」判断や、許可のない行動に変えてはいけません。
ユーザーは常時稼働の見張りをどうやって止められますか？
Comma では、Loop の一時停止や削除を頼めます。接続したコンピューターへのアクセスも、操作を無効にすれば読み取り専用に戻せます。常時稼働の責任には、わかりやすい範囲、目に見える状態、実際に使える停止スイッチが常にあるべきです。
シグナルを、役に立つ次の一歩に変える
まずはイベントの発生元を 1 つ選び、何が起きたら計画が実質的に変わるのか、行動できる時間枠はどれくらい開いているのか、どの判断を自分の手に残すべきなのかを書き出してみてください。主体的な注意が Task や確認とどうつながるかは Comma のエージェント で、現在の監視のしくみと制限は Loop のドキュメント でご覧いただけます。
