Anthropicは2026年11月13日に「Building always-on agents」（著者はWilliam Hu）を公開しました。公式が24時間待機のAIアシスタントをどう作るかを解説したもので、イベントインボックス（event inbox）、タイマー（timers）、記憶（memory）、権限（permissions）、アウトボックス（outbox）の5つの部品に分けています。
Always-on agent（常駐型AIアシスタント）は、自分から起きて作業するAIです。もう少し詳しい説明はAlways-on agentとはをご覧ください。
Always-on agentは、実はほとんど眠っている
Anthropicは、「常にオンライン」というのはユーザーの体感にすぎないと言います。agentはほとんどの時間を眠っていて、token（AIの利用量を測る課金単位）も使いません。イベントが届くと起きて、run（1回の実行）を1回行います。イベントを受け取り、session（会話の記録）を開き、agent loopを回して、結果を保存済みの状態に書き戻します。終わったらまた眠る。この繰り返しです。
中心のループは通常のagentと同じです。違いはその外側にあります。いつ起きるか、run同士の間に何を残すか、結果をどうあなたに届けるか、という部分です。
なぜ今になって作れるようになったのか
Anthropicは2つの理由を挙げています。1つ目は、新しいモデルの判断力が上がり、ユーザーの意図をよく理解し、いつ報告すべきかも分かるようになったことです。2つ目は、知能が安くなったことで、とくに長いタスクが恩恵を受けています。長時間のコーディングテストでは、Opus 5.5が1問解くコストはOpus 5より78%低く、通常の作業量では40%低いだけでした。長いタスクが大幅に安くなり、always-on agentもより現実的に動かせます。Opus 5.5の詳細はClaude Opus 5.5の紹介をご覧ください。
イベントインボックス：すべてのイベントはまず列に並ぶ
通常のAIは、あなたがメッセージを送ったときだけ動きます。ここではトリガーがもっと多く、webhook（他のシステムから届く通知）、スケジュールされたタスク、バックグラウンドの処理があります。
各ソースがagentを直接呼び出すと問題が起きます。2つのイベントが同時に届くと、互いに衝突するrunが起動します。クラッシュしたときには、イベントが跡形もなく消えます。
そこで、すべてのソースはイベントをインボックスに入れるだけにして、worker（バックグラウンドのプログラム）がそこから取り出します。最も簡単な構成は3つです。
- イベントを記録するデータベースのテーブル
- イベントを書き込む受け口
- イベントを読み出すworker
受け口はすばやく応答する必要があります。prompt injection（コンテンツに仕込まれた、AIをだまして従わせようとする悪意ある指示）のような踏み込んだチェックは、runの中で行います。基準はあくまでインボックスなので、workerが落ちても、新しいworkerが同じイベントを拾ってやり直せます。同じインボックスを同時に扱うworkerは1つだけです。続けて届いた複数のメッセージは1回のrunにまとめられ、agentの返信も1回で済みます。
タイマー：agentが自分で次の起床を予約する
自分から動くにはタイマーも必要です。種類は2つあります。
- フォローアップ（follow-up）： agentが自分に設定する期限です。たとえば、相手から返信が来たかをあとで確認します。
- スケジュール（schedule）： 決まった周期のタスクです。たとえば、毎日のニュースレターです。
タイマーは専用のテーブルに入れ、インボックスには処理可能になったイベントだけを入れます。タイマー自身はrunを起動しません。scheduler（スケジュールを管理するプログラム）が定期的にスキャンして、期限が来たものをイベントにしてインボックスへ入れます。
記憶：起きるたびに、これでつながる
runとrunの間は途切れています。連続性は記憶が支えます。Claude Codeのauto memoryも、Messages APIのmemory toolも、記憶をフォルダ内のファイルとして作ります。Always-on agentでは、このフォルダをデータベースやオブジェクトストレージのような永続的な場所に置きます。workerが入れ替わっても、記憶は残ります。
原則は、調べ直せないものだけを保存することです。データがすでに別のシステム（たとえば課題管理ツール）にあるなら、その場所を指すポインタだけを保存します。記憶は4種類あります。
- ユーザーの指示： 1つのファイルにまとめ、毎回のrunで読み込みます。ユーザーが常にそばで指示してくれるわけではないからです。
- ユーザーのメモ： 役割、好み、ユーザーが訂正した点です。読み込むのは索引だけで、詳細は必要なときに読みます。
- 過去のメッセージ： すでにユーザーへ伝えた内容です。繰り返しを避けるために使います。
- タスクの進捗： タスクごとに1つの進捗ファイルを作ります。新しいrunはそれを読めば続きから作業できます。
さらにdreamingを加えることもできます。過去のsessionを見直して記憶を整理し、古い項目を置き換え、複数のrunをまたいではじめて見えるパターンを探すものです。Claude Managed Agentsにはすでに同様の機能があります。詳しくはClaude Managed Agents Dreamsとはをご覧ください。記憶の基本はAI Agentの記憶の仕組みで解説しています。
各runの冒頭で、agentはsystem prompt、ツール定義、記憶ファイルを読み込みます。これは毎回払うコストなので、できるだけ絞り、prompt caching（繰り返し出てくる冒頭部分をキャッシュして費用を抑える仕組み）を使います。新しいsessionにはこの内容とトリガーになったイベントだけが入りますが、既存のsessionには以前のメッセージがすべて戻ってきます。
長くなりすぎたときは、compaction（古いメッセージを要約に圧縮すること）を行うか、新しいsessionを開きます。どちらも細部が抜け落ちるので、重要なことは先に記憶へ保存しておく必要があります。
権限：リスクがいちばん集中する場所
Anthropicは、権限が最もリスクの高い部分だと指摘しています。1回のrunがユーザーのアクセス権を持ったまま、誰も見ていないところで動くからです。ツールを呼び出すたびに、agentは、そのまま実行するか、止めるか、人の承認を待つかを決めます。方法は3つあります。
- 認証情報をagentの外に置く： パスワードやアクセストークンのような認証情報は、agentの環境の外にあるプロキシサーバー（proxy）に預けます。リクエストを送る時点で付け足されるので、agent自身は持っていません。
- Auto mode： Claude Codeと同じように、分類器がリスクの高い操作を審査し、危険なものは止めて、Claudeに安全な別の方法を取らせます。最も重要な判断は、やはりユーザーが確認します。
- Deferred tool call（延期されたツール呼び出し）： 承認が必要になると、そのrunは終了し、sessionは呼び出しの途中の状態で保存されます。リクエストはユーザーにインタラクティブなカードとして表示され（Anthropicの例はMCP Appsで作ったインターフェース）、返答はイベントとしてインボックスに入り、新しいrunが続きを実行します。待っている間も、workerは別のイベントを処理できます。
そのほかのリスクはAI Agentのセキュリティリスクをご覧ください。
アウトボックス：伝えるのは結果で、過程ではない
通常のAIは考える過程をそのままリアルタイムで流します。Always-on agentはバックグラウンドで作業するので、あなたに届くのは結果と要点だけです。
1回のrunの終わり方は3通りです。メッセージを送る、伝えることはないと判断する、延期されたツール呼び出しであなたに尋ねる、です。多くのagentは「send」ツールで直接送れば十分です。メッセージを送るペースを調整したり、エラーから復旧したりしたい場合に、正式なアウトボックスが必要になります。送信待ちメッセージのテーブルと、どれを送るかを決めるdispatcher（送信を振り分けるプログラム）で構成します。
メッセージの量は調整が必要です。多すぎるとうるさく、少なすぎると見落としが出ます。Anthropicは、eval（テスト）でバランスを探し、静かな状態から始めて、少しずつあなたの注意を得ていくことを勧めています。
5つの部品のつながり方
どのrunも、インボックスにある1つのイベントから始まります。ユーザーのメッセージ、webhook、タイマーのいずれかです。workerがagentを起こし、新しいsessionか既存のsessionを使います。agentはまず記憶を読み、権限の範囲内で作業し、学んだことを記憶に書き戻し、最後にアウトボックスへ1件入れます。それをdispatcherがあなたに届けます。
runはタイマーを設定して、あとで自分を起こすこともできます。あなたの返信は、またイベントとしてインボックスに戻ります。1回ごとのrunは短く、サイクルは止まらないので、agentは常にオンラインのように見えます。
Rubric Labsのやり方との違い
エンジニアリングチームのRubric Labsの設計は、途切れない1本の会話スレッドを使い、heartbeat（会話に定期的に差し込まれるメッセージ）でagentを起こします。メッセージを送ることもツールなので、agentは今回はあなたに連絡しないと決められます。ほかにも、幅広いアクセス権と通知インボックスを持っています。
両者とも、ツールで通知するかどうかを決め、インボックスで外部のイベントを受けています。違いは、Rubric Labsはスレッドが1本だけなのに対し、Anthropicはagentが起きるたびに短いrunを1回実行し、新しいsessionを開くことも以前のsessionに戻ることもできる点です。長期に残したい情報は記憶ファイルに保存します。スケジュールや分身の基本的なやり方はSkill、Sub-agent、Cronの3大機能をご覧ください。
always-on製品を見極める3つの質問
- イベントはどう入ってくるか。インボックスがあるのか、それとも各ソースが直接agentを呼んでいるのか。
- 何を覚えているか。指示、メモ、すでに伝えた内容、タスクの進捗が分けて保存されているか。
- 何ができるか。アカウントの認証情報はagentの手元にあるか、リスクの高い操作は誰が承認するか。
メッセージの送信については、Anthropicは、agentが静かな状態から始め、evalでメッセージ量を調整して、少しずつあなたの注意を得ていくことを勧めています。
表紙と本文の画像出典：Anthropic（claude.com/resources/articles/building-always-on-agents）
本記事はAI agentの設計の考え方を整理したもので、証券や投資の助言ではありません。