常時稼働の AI エージェントとは、会話が開かれていないときでも仕事に責任を持ち続けられるエージェントのことです。任務の状態を保ち、時間の経過や外の世界の変化を待ち、適切な環境で再開し、次の判断が人に属するときには主導権を戻します。
「常時稼働」は、大規模言語モデルが休みなく考え続けるという意味ではありません。コンピューターが昼も夜もフル稼働で資源を使い続けるという意味でもありません。そしてエージェントが絶えずメッセージを送ったり、許可なく行動したりするという意味であってもいけません。役に立つ約束とは連続性です。システムのほとんどが眠っている間も、責任は生き続けます。
プロンプトを予約実行したり、チャット履歴を残したりするだけでは、実際の問いには答えられません。再起動のあと何が残るのか、何がエージェントを起こすのか、どこで作業を続けるのか、ユーザーはどうやって止められるのか。これらの問いへの答えが、「24/7」をスローガンからシステムの性質に変えます。
常時稼働とは稼働時間ではなく連続性のこと
稼働時間は、プロセスが動いているかどうかを表します。連続性は、その仕事にまだ担い手がいて、有効な次の一歩があるかどうかを表します。
署名済みの契約書が戻ってくるのを見張り、届いたらローンチのチェックリストを更新し、次の判断を用意しておくようエージェントに頼んだとしましょう。契約書は明日戻るかもしれないし、来週かもしれません。その待ち時間の間、役に立つ推論は起きていません。エージェントに必要なのは、開いたチャットでも、温まったままのモデルのセッションでも、受信トレイを毎分更新するブラウザーでもありません。必要なのは責任の永続的な記録と、関連する出来事がその責任を確実に再び動かせる仕組みです。
この違いは障害のときにはっきりします。プロセスがずっと動いていても、クラッシュのあとに任務を失うことがあります。別のシステムは何時間もゼロまでスケールダウンし、出来事が届いたときに状態を組み立て直して正しく再開できます。より意味のある形で常時稼働しているのは後者です。
だからこそ、永続的なエージェントの基盤は、待つことと計算することを切り離します。たとえば Microsoft の現在の Agent Framework の Durable Extension は、ワーカーの実行をまたいで状態を保ち、計算資源やモデルのトークンを使わずに一時停止し、外部の出来事から再開するエージェントを説明しています。Google の イベント駆動で再開する長時間稼働エージェント のガイドも、永続的なチェックポイントと webhook で同じ原則を示しています。実装の細部は違っても、アーキテクチャの教訓は変わりません。常時稼働の責任に、常に動き続けるモデルは必要ないのです。
信頼できる常時稼働エージェントを支える 6 つの条件
エージェントを常時稼働にする単一の機能はありません。この性質は、6 つの条件が一緒に働いたときに生まれます。
継続するアイデンティティが責任を担う
システムには、メッセージ、出来事、権限、タスク、ユーザーの期待を結びつけられる、安定したアイデンティティが必要です。会話のたびに、運用の文脈を共有しない無関係なエージェントが作られるなら、あとから届く出来事が起こすべき相手はおらず、仕事を続ける責任を負う者もいません。
継続するアイデンティティに無限の記憶は要りません。ユーザーが同じエージェントに戻ってこられ、システムがどの責任がそのエージェントに属するかを知っている、という意味です。個人に関する事実、会話の履歴、タスクの状態は、それぞれ違う寿命と管理のしかたを持てます。
作業状態がアイドル時間を生き延びる
任務には、最初のプロンプト以上のものを残しておく必要があります。再開に必要な状態には、目指す成果、完了した操作、作業中の成果物、制約、いまの障害、そして有効な次の一歩が含まれることがあります。
その状態は、ふだんの中断に耐えられるほど永続的であるべきです。閉じたブラウザー、スリープしたコンピューター、デプロイされた更新、ワーカーの再起動、あるいは数日の経過です。会話の記録は何が起きたかを組み立て直す助けにはなりますが、組み立て直すことと回復することは同じではありません。信頼できるシステムは、起きるたびに長い会話からモデルに真実を推測させるのではなく、どの状態が正であるかを知っています。
1 つの任務を依存関係をまたいで運ぶ ためのより深い仕組みは、この分野の定義とは別の問題です。この段階でのテストはもっと単純です。システムは、改めて説明を受けなくても続けられるだけの有効な状態を保てるでしょうか。
時間と出来事がシステムに入ってこられる
外の世界の仕事は、ユーザーがメッセージを送ったときだけ進むわけではありません。期限が来ます。ファイルが変わります。返信が届きます。デバイスがオンラインに戻ります。承認が別のアプリケーションで記録されます。
ですから常時稼働のエージェントには、対話用の入力欄以上のものが必要です。タイマーや外部の出来事が、影響を受ける責任まで届く経路が必要なのです。その経路は webhook、メッセージキュー、スケジュール、コネクター、範囲を狭く絞った監視プロセスなどでありえます。大事なのは、その出来事を正しいエージェントと正しい状態に結びつけられることです。
これは、すべての出来事が完全な推論の実行に値するという意味ではありません。イベント駆動の動作に価値があるのは、評価すべき仕事が生まれるまでシステムのほとんどが静かなままでいられるからです。ある出来事がメインのエージェントを起こすべきかどうか、そしてその目覚めが人の邪魔をすべきかどうかを決めるのは、常時稼働のシステムそのものを定義するのとは別の方針の問題です。
仕事を再開するときに実行環境が使える
次の一歩を覚えていても、それを行う場所がなければ足りません。API で済む仕事もあります。ブラウザー、クラウドコンピューター、ローカルのマシン、専用のエージェントランタイムが必要な仕事もあります。責任が再び動き出すとき、次の一歩に必要なファイル、ツール、権限を備えた環境が使えなければなりません。
「使える」とは、常に動いているという意味ではありません。クラウドコンピューターはストレージを保ったまま眠り、必要なときに起きられます。ローカルのマシンは、タスクが必要とするまで接続されていなくても構いません。大事なのは、エージェントが必要な環境を見分け、それがない状況に誠実に対処できることです。
環境の境界も正しさの一部です。Comma の デバイスのドキュメント には、Salix がオフラインのデバイスから別のコンピューターへ黙って仕事を移すことはない、と書かれています。リクエストは失敗し、そのデバイスが戻ったときに再試行できます。どのコンピューターでも入れ替えがきくふりをするよりは魔法っぽさに欠けますが、仕事が頼っている場所、アクセス、実行の条件は守られます。
回復は通常運用の一部
常時稼働のシステムは、いずれ再起動、重複した出来事、使えないサービス、期限切れの認証情報、切れた接続に出会います。ですから信頼性は、1 つのプロセスが永遠に完璧であり続けることに頼れません。
システムには回復の道筋が必要です。永続的な状態、チェックポイントまたはそれに相当する正の情報源、回数に上限のある再試行、外部への操作を繰り返さないための手段、そして自動回復がもう安全でないときの目に見える失敗状態です。すでに確認されたことを黙って忘れる再起動は回復ではありません。結果を変えないまま資源を使い続ける無限の再試行ループも回復ではありません。
Comma の Loop のドキュメント に具体例があります。Loop はチェックポイントを保存し、再び起動したときにそれを受け取れます。障害のあと、Salix は上限のある再試行ポリシーの範囲でそのチェックポイントから Loop を再起動し、失敗が続くと Loop を止めてエージェントに知らせます。永続的なイベント、重複の排除、配置、機能の制限を含む実装の全体は、分散エージェントハーネスのためのプログラマブルなイベントループ で説明しています。製品を評価するときは、中断と回復が想定外ではなく計画された状態になっているかを確かめてください。
ユーザーが連続性を見て、制約できる
持続するほど、管理の重要性は増します。一度きりのチャットは自然に終わります。バックグラウンドの責任には、わかりやすい範囲、目に見える状態、そして実際に効くオフスイッチが必要です。
ユーザーは、エージェントが何に責任を持っているか、どの情報源を見張っているか、どの環境を使えるか、そこでどんな権限があるかを知ることができるべきです。責任を一時停止したり終わらせたり、アクセスを取り消したり、すでに生み出された成果を取り戻したりできるべきです。システムは、沈黙をすべて順調である証拠とみなすのではなく、失敗や結果を伴う判断を表に出すべきです。
常時稼働と自律が同義語でないのも、このためです。持続性とは、システムが使える状態であり続けられることを表します。自律とは、尋ねずにどの判断や行動をしてよいかを表します。エージェントはとても持続的でありながら、あえて慎重でいられます。準備し、確かめ、整理し、待ちながら、外部への約束や取り消せない選択はユーザーに戻せるのです。
終わりのない 1 回の実行ではなく、4 つの動作モード
「常時稼働」という言葉は、1 つの連続した活動を思わせます。実際には、役に立つエージェントはいくつかのはっきり異なるモードを行き来します。
モデルとツールが任務を積極的に進めている作業中のこともあります。時刻、出来事、環境、人の判断がまだ届いていないために待機中のこともあります。軽量な見張り役が、メインのエージェントを起こさずに狭い条件を監視中のこともあります。あるいは、ユーザーが終わらせたか、障害が安全な回復の方針を超えたために、責任が停止していることもあります。
これらのモードは、信頼性と同じくらいコストと注意にとっても重要です。モデルの推論、クラウドの計算、イベントの取り込み、ストレージ、外部の API は、それぞれ課金のしかたが違うことがあります。製品はそれらをひとまとめにして、「エージェントが 24/7 動きます」という条件なしの主張にすべきではありません。静かなバックグラウンドの責任は、ストレージと監視の資源を使いながら大きなモデルのトークンをまったく使わないこともあります。動いているタスクはモデルと計算の両方の資源を使うことがあります。停止した責任は、保持された状態以外には、どちらも使うべきではありません。
Comma は自らのランタイムでこの区別を反映しています。Salix は、常に温まったままのサンドボックスの外でエージェントを動かします。コンピューターでの作業が必要になると、使用の合間もストレージが保たれるクラウドの仮想マシンを起こせます。継続的な注意のためには、小さな Loop がメインのエージェントループを動かし続けずに出来事を見張れます。Loop がエージェントの出番だと判断したときにだけ、メインのループが動きます。
このアーキテクチャは Comma の実装であって、普遍的な定義ではありません。別の製品は、永続的なワークフロー、キュー、サーバーレス関数、長時間動くワーカーを使うかもしれません。試されるのは、特定のランタイムを使っているかどうかではなく、システム全体がアイドルの期間を通じて責任を守れるかどうかです。
常時稼働、スケジュール実行、長時間稼働は別の約束
スケジュールされた自動化は、決まった時刻に指示を実行します。継続するエージェントのアイデンティティを保たなくても、予定外の変化に応えなくても、とても役に立つことがあります。毎日のジョブが決まった入力からレポートを作るだけなら、スケジュールさえあれば十分かもしれません。
長時間稼働のワークフローは、いくつもの段階をまたいで状態を保ち、合図を待てます。モデルが情報の解釈、ツールの選択、計画の調整に関わると、それはエージェント的になります。その永続的なワークフローが、関連する新しい出来事を受け取り、ユーザーが管理する境界の中で行動できる継続的なエージェントに属したとき、それは意味のある形で常時稼働になります。
チャットボットも過去の会話を覚え、リマインダーを出せます。こうした機能はユーザーにとっての連続性を高めますが、それだけで仕事がチャットの外でも続いていることの証明にはなりません。決め手となる問いは、システムがあなたについて何かを覚えているかではありません。動いている責任が、手作業で作り直されることなく、待ち、再開し、回復し、許可された環境に届けるかどうかです。
この区別は作り込みすぎも防ぎます。すべての依頼に常時稼働のエージェントが必要なわけではありません。一度きりの説明、書き直し、計算、ブレインストーミングは、対話型のモデルで済ませるほうがよいことが多いものです。常時稼働の動作がその複雑さに見合うのは、成果が時間、外部の変化、複数の作業環境、あるいは今の会話が終わっても開いたままの責任にかかっているときです。
連続性を確かめる実践的なテスト
「常時稼働」をうたう製品を評価するなら、すき間を含む現実的な責任を 1 つ与えてみてください。決まった条件を監視し、次の一歩を用意し、結果を伴う行動の前で止まるよう頼みます。
そのうえで、製品が何を見せてくれるかを確かめます。画面を閉じたあと、任務はどこに保存されていますか。正確にはどんな条件で再び動き出しますか。作業の資料がどの環境にあるかを知っていますか。再起動のあと、完了した操作を繰り返さずに再開できますか。出来事が重複したり、必要なデバイスがオフラインだったりしたら何が起きますか。履歴をすべて消さずに、監視を止めたり、アクセスを取り消したり、任務を終わらせたりできますか。
最後に、あなたのところに何が届くかを見てください。すべての出来事を転送するシステムが作ったのは通知のパイプラインであって、エージェントとは限りません。すべての出来事に行動するシステムは、可用性と権限を取り違えています。役に立つ常時稼働のエージェントは、変化を既存の責任に結びつけ、すでに許された仕事をこなし、注意を向けることで結果が変わるときにだけ注意を求めます。
Comma は騒がしくならずに使える状態をどう保つか
Comma は無料でオープンソースのパーソナルエージェントで、会話とデバイスをまたぐ 1 つの継続したエージェントを中心に設計されています。ちょっとした質問はチャットのままで構いません。大きな責任は Task になります。Comma は、連携したアプリとファイル、接続した Mac や Linux のデバイス、必要なときに起きるクラウドコンピューターで働けます。
その常時稼働の層が Salix です。Comma のエージェントは、受信トレイ、リポジトリ、フィード、API、webhook のような範囲の決まった情報源を見張る Loop を作れます。Loop はメインの推論ループとは別に動き、小さなチェックポイントを保ち、仕事が必要になったときにエージェントへ知らせられます。メインのエージェントが静かな時間を逐一確かめる必要がないので、「いつでも使える」が「いつでもモデルのトークンを使っている」にはなりません。それでも Loop は高速な判断用のモデルや他のサービスを呼ぶことがあるので、バックグラウンドの作業が自動的に無料になるわけではありません。コストは Loop が実際に何をするかで決まります。
同じ連続性は、ユーザーの管理のもとにあり続けます。接続したコンピューターは、ユーザーが操作を許可するまで読み取り専用で始まり、デバイスへのアクセスは取り消せます。Loop には機能と起床回数の制限があります。判断がユーザーに属するときには、大きな Task が 要確認 に戻れます。Comma は セルフホスト もできますが、その場合はインスタンスを動かし続けるのに必要な可用性、アップグレード、バックアップ、モデル設定などのインフラを運用者が担います。
Comma のアプローチは、この分野の中心的な問題への 1 つの答えです。責任は持続させながら、高価な計算、モデル、ユーザーの注意は、本当に必要になるまで休ませておくのです。
よくある質問
常時稼働の AI エージェントはモデルを 24/7 動かしているのですか？
いいえ。よく設計されたシステムは、メインのモデルが動いていない間も状態を保ち、タイマーや出来事を待てます。モデルが動くのは、システムが推論や生成を必要とするときです。エージェントが待っている間も、軽量な監視、ストレージ、外部のサービスは資源を使うことがあります。
常時稼働のエージェントは自律エージェントと同じですか？
いいえ。常時稼働は、時間をまたいだ連続性と可用性を表します。自律は、人の承認なしにエージェントが何を決め、何をしてよいかを表します。常時稼働のエージェントは狭い権限で動き、結果を伴う判断をユーザーに戻せます。
スケジュールされた AI のタスクは常時稼働のエージェントですか？
そうとは限りません。スケジュールは、状態を持たないプロンプトを決まった時刻に起動できます。常時稼働のエージェントはそれに加えて、責任と関連する状態を保ち、適切な外部の出来事に応え、中断から回復し、ユーザーによる継続的な管理の範囲で仕事を続けます。
エージェントのコンピューターは動かしたままにしておく必要がありますか？
必要な環境によります。クラウドやサーバー側の作業は、個人のノートパソコンを閉じても続けられます。特定のローカルのデバイスにしかないファイルやアプリケーションに頼る作業は、そのデバイスを待つしかありません。クラウドの環境の中には、ストレージを保ったまま操作の合間に眠れるものもあります。
常時稼働のエージェントが失敗したらどうなりますか？
システムは、わかっているチェックポイントや永続的な状態から回復し、完了した外部への操作を繰り返さず、上限のある再試行を使うべきです。安全に回復できない場合は、いつまでも再試行したり黙って責任を放り出したりせず、目に見える形で止まり、何が失敗したかをエージェントやユーザーに伝えるべきです。
常時稼働のエージェントはオフにできますか？
バックグラウンドの責任を一時停止したり終わらせたりでき、それが使うアクセスを取り消せるべきです。「常時稼働」とは、許可されたときに使えることであって、止められないことではありません。Comma では Loop を一時停止したり削除したり でき、連携したデバイスへのアクセスも取り消せます。
エージェントは眠れても、責任は消えない
常時稼働の AI エージェントを定義するのは、モデルの絶え間ない活動ではありません。途切れない責任の連なりです。安定した担い手、永続する状態、時間と出来事が意味を持つための経路、使える実行環境、回復できる運用、そしてユーザーの手に残る管理です。
これらがそろえば、システムのほとんどはほとんどの時間静かでいられます。モデルは止まれます。クラウドコンピューターは眠れます。ユーザーはアプリを閉じられます。仕事が再開するのは、誰かが「続けて」と入力するのを覚えていたからではなく、責任がまだ損なわれずに残っているからです。
