チャットボットには共通点があります。メッセージを送らなければ、何もしないことです。エンジニアリングチームのRubric Labsは、2026年11月5日に「Designing an Always-On Agent」を公開し、まさにこの問題の解決に取り組みました。著者のDexter Storey氏の目標は、映画『アイアンマン』のJarvisのように、いつも待機しているAIを作ることです。
Always-on agentとは
Always-on agentは「常駐型AIアシスタント」と呼べます。Rubric Labsは、次の3つの特徴で定義しています。
- 単一スレッド（single-threaded）：話す相手は1つのAIだけで、AIはあなたを覚えていて、すべてを任せられる
- 能動的（proactive）：誰にも呼ばれなくても、自分から作業し、あなたにメッセージを送る
- 状況認識（situationally aware）：あなたの予定、メール、周囲の状況を把握していて、毎回背景を説明しなくてよい
いまのチャットボットや通常のAI Agentと比べると、Rubric Labsの説明は次のとおりです。
| 常駐型AIアシスタント | 通常のチャットボットやagent | |
|---|---|---|
| 存在のしかた | 長期にわたる1本のスレッド | 一時的で、使い終わると閉じる |
| 起動のしかた | 自分で起きる | 受け身で、あなたが話しかけたときだけ動く |
| 情報源 | 自分で環境を把握する | あなたがその場で渡した内容だけ |
単一スレッド：記憶をあふれさせない方法
すべてを1つの会話に入れると、コンテキストウィンドウ（AIが一度に読める文章量のことで、いっぱいになると読み込めなくなります）の上限にぶつかります。同じ会話の中で、予定の調整も、食事の注文も、メールの返信もさせたいなら、この問題に対処しなければなりません。Rubric Labsは2つの方法を使っています。
エージェント自身に記憶を整理させる。 業界でよくある方法はコンパクション（圧縮）で、会話が長くなったら前半を要約に縮めます。Rubric Labsは、外部のプログラムが代わりに圧縮するとリズムが崩れ、エージェントの思考と勢いをばっさり断ち切るようなものになると気づきました。
そこで、次のようにしました。
- エージェントが毎ターン、自分のトークン使用量を確認できるようにする
foldContextツールで、メッセージの範囲を自分で書いた要約に置き換えさせるdropContextツールで、メッセージの範囲を直接削除させる
実際には、エージェントはたいてい、1つの作業が終わった合間を待ってから圧縮します。もう要らない推論やツールの記録を捨て、使っている内容を残します。AIの記憶の仕組みを先に知りたい方は、AI Agentの記憶メカニズムをご覧ください。
手間のかかる作業はサブエージェントに任せる。 食事の注文や予約のように、ブラウザを操作する作業は時間がかかります。メインのエージェントはそれらをsub-agent（分身）に渡して自分はあなたとの会話を続け、メインのスレッドにも全体の流れを置く余裕が残ります。分身の仕組みはSkill、Sub-agent、Cronの3つの仕組みが参考になります。
能動性：ハートビートとメッセージ送信ツール
通常のエージェントは関数のようなものです。リクエストを送ると、結果が返ってきます。能動的になるには、いつでも起きられて、あなたから話しかけられるのを待たずにメッセージを送れる必要があります。Rubric Labsは2つの設計を加えました。
ハートビート（heartbeat）。 一定の間隔で、システムが会話に「heartbeat」というメッセージを差し込み、エージェントが起きます。間隔は1時間ごとなどに固定することも、エージェント自身に次に起きる時刻を決めさせることもできます。
「あなたへのメッセージ」をツールにする。 普通のチャットでは、エージェントが各ターンの最後に書いた一文が、そのまま返事になります。この設計では、エージェントがメッセージ送信ツールを呼び出さないかぎり、あなたには届きません。そのため、起きて作業を終えたあと、今回は伝えるほどのことはないと判断して、あなたの邪魔をしないこともできます。最後の一文は、エージェント自身へのメモとして会話に残ります。
Rubric Labsが挙げている例です。エージェントは、あなたが水曜にオースティンへ飛ぶことを知っています。通常のハートビートで便の情報を見つけると、分身に空港から宿までの道順とチェックイン情報をまとめさせ、着陸時刻の近くにハートビートを予約して、あなたが着陸したタイミングでメッセージを届けます。
状況認識：広い権限と通知インボックス
エージェントが自分でやることを見つけるには、あなたの状況を知っている必要があります。Rubric Labsは2つの層を用意しています。
広い権限。 エージェントにメールボックス、ブラウザ、ファイルを読ませれば、あなたが予約した航空券や宿泊先を自分で見つけ、好みも把握できます。Rubric Labsは、コーディングAIが「ターミナルコマンドを実行する」という1つのツールで強くなったように、汎用エージェントもコンピュータ操作ツールで似たことができると考えています。
通知システム。 権限だけでは足りません。エージェントは、自分が何を知らないのかを知らないからです。そこでRubric Labsは、インターネット上の出来事が起きるとすぐに届くインボックスを渡しています。フライトが欠航になれば、エージェントはすぐに代わりの便を探してあなたに知らせられ、1時間後に気づくことがありません。
そこで問題が出ます。インボックスはすぐに、広告メール、自分宛てではないSlackのメッセージ、関係のないプログラミングプロジェクトの通知でいっぱいになります。どれもエージェントを起こすなら、毎分起きることになり、トークン（AIの利用量の課金単位）が無駄に燃えてしまいます。Rubric Labsが挙げるやり方の一つは、まず小さなモデルに重要かどうかを判断させることです。重要なものだけがエージェントを起こし、ほかはたまっていき、エージェントに余裕があるときにまとめて読ませます。
いちばん難しいところ：判断力
Storey氏は、ここまでの構成は比較的単純な組み合わせで、本当の難問はモデル自体にあると述べています。
「いまのモデルはこれがとても苦手です。判断力が足りないからです。」
氏の説明では、いまのモデルは訓練の段階で「タスクを完了させる」ことを学んでいるため、シグナルがはっきりしていれば強く、曖昧な環境では問題が起きます。氏が挙げる例はSlackで、エージェントは自分宛てではないメッセージに手を出し、権限も背景もないと気づいたあげく、設計ドキュメントを提出します。氏の評価は、役に立たず、しかも恥ずかしいというものです。逆に、本来動くべきときを見逃すこともあります。積極的すぎる状態と消極的すぎる状態のバランスは、公式に当てはめて調整するより、経験で探っていくものだと氏は考えています。
氏のすすめは、エージェントを最初は恥ずかしがり屋にして、少しずつ自信をつけさせ、自分が力を発揮できる範囲を見つけさせることです。具体的には3つあります。
- システムプロンプト（system prompt）に、何を担当するのかを明記し、「何もしない」のも全く問題ないと伝える
- 自分の仕事かどうか分からないときは、推測せずに先に聞く
- 行動のたびにあなたがどう反応したか（感謝、訂正、無視）を記憶し、次の行動の前にその記憶を確認する
初心者への3つの注意
- これは設計の考え方です。記事には実測データがなく、効果がどれほどかも書かれていません。常駐型AIを理解するための地図として受け取ってください。
- 権限が広いほどエージェントにできることは増えますが、ミスや悪用のリスクも大きくなります。AI Agentのセキュリティリスクもあわせてご覧ください。
- エージェントと言語モデルの役割分担を先に理解したいなら、AI AgentはAIではないから読み始めるのがおすすめです。