長時間動くAIエージェントで本当に困るのは、モデルが一度失敗することだけではありません。セッションやプロセスが消えたとき、未完了の目的まで一緒に消えてしまうことです。

2026年8月15日に公開されたLooperの設計記録は、エージェントを組織図のように増やす方向から、PostgreSQLに仕事を残して交換可能なワーカーへ渡す方向へ軸足を移しています。ただし、監査で見つかった問題は実測値である一方、新しい設計は構築中で、まだ有効性を証明できていません。

では、PostgreSQLを中心に置くと何が変わり、どこから先はデータベースだけでは守れないのでしょうか。仕事の永続化、排他制御、検証、外部副作用の順にたどると、この設計を採用する条件が見えてきます。

エージェントではなく「未完了の仕事」を永続化する理由

Looperの監査では、実行された16ループのうち8個以上が観測専用で、外部を変更したものは3個だけでした。45夜のうち43夜でセンサーが赤を報告した一方、検証済みの自律的な修正完了は0件です。検知する仕組みは動いていても、検知結果を次の行動へ結び付ける代謝がありませんでした。

実行ログが何千件残っていても、「この目的はまだ未完了である」というレコードがなければ、次のワーカーは前回の文脈を再構築するところから始まります。そこで再設計では、会話や常駐エージェントではなく、1件の未完了仕事を表すcampaign行を耐久性のある中心オブジェクトにします。

campaign行に残す情報	次の処理で必要になる理由
目標状態と観測結果	なぜ仕事が開かれたかを再現する
現在状態	実行、検証、確認のどこまで進んだかを区別する
リース所有者、有効期限、世代番号	死んだワーカーから仕事を回収し、古い結果を拒否する
試行回数、次回時刻、失敗理由	同じ試行の無限反復を避ける
受け入れ条件と証拠の場所	自己申告ではなく結果で完了を判定する

ワーカーはこの行を獲得し、分離した作業環境で1回試行し、結果を記録して終了します。プロセスが落ちても失うのは1回の試行であり、目的そのものではありません。ここが「エージェントを再起動する」と「仕事を再開する」の違いですね。

PostgreSQLの行ロックとリースは異なる時間幅を守る

複数ワーカーが同じ仕事を取らないようにする入口には、SELECT ... FOR UPDATE SKIP LOCKEDを使えます。PostgreSQL 18のSELECTドキュメントも、SKIP LOCKEDは一貫した一般参照には向かない一方、キュー状テーブルを複数コンシューマーが処理するときの競合回避に使えると説明しています。

この機能はAIエージェント向けに生まれたものではありません。PostgreSQL 9.5のリリースノートによれば、9.5は2016年1月7日に公開され、SKIP LOCKEDが追加されました。新しいエージェント設計を、成熟したジョブキュー向け部品で支える構図です。

ただし、行ロックが守るのはトランザクション中です。ワーカーがロックを保持したまま数分から数時間の外部処理を行う設計にはせず、短いトランザクションで所有者、有効期限、単調増加する世代番号をcampaign行へ書きます。処理結果を受け取る側は、現在の世代番号と一致した結果だけを採用します。

このリースと世代番号はPostgreSQLが自動で完成させてくれる機能ではなく、アプリケーション側の規約です。期限切れを回収するreaperも、仕事を配るプロセスとは独立して動かさなければ、配布側の停止と一緒に復旧経路まで止まってしまいます。

状態遷移と証拠を同じトランザクションへ結び付ける

仕事の状態をattemptedから一気にconfirmedへ進められるなら、台帳があっても自己申告を保存しただけです。ready、leased、attempted、verified、confirmedのように段階を分け、誰がどの遷移を実行できるかを決めます。

PostgreSQLのトリガーは、トリガー元の文と同じトランザクション内で実行され、どちらかが失敗すれば双方がロールバックされます。合法な遷移だけを許可し、状態変更とイベント行の追加を同じトランザクションで必須にすれば、「状態は変わったが監査記録がない」という分岐をデータベース内では防げます。

外部への操作は別問題です。Gitの参照更新、API呼び出し、メッセージ送信はPostgreSQLのトランザクションに含まれません。AWSのTransactional Outbox解説が示すように、状態更新と送信予定イベントを同じトランザクションへ保存すると二重書きの不整合を減らせますが、配送の重複に備えて受信側の冪等性も必要です。

そのため、外部操作の前にintentを記録し、期待するGit SHAや冪等性キーを付け、実行後に読み戻して結果を記録する流れになります。データベースの世代番号は古いワーカーによるDB更新を拒否できても、すでに始まった外部プロセスを止める柵にはなりません。

書き込みAPIと独立検証でワーカーの権限を狭める

再設計では、ワーカーへ汎用的なDB資格情報を渡さず、カーネルが狭いstored functionを呼ぶ形を目指しています。これは「実行能力」と「今この仕事で許可された操作」を分けるための設計です。

実装時には、SECURITY DEFINERを付けるだけでは不十分です。PostgreSQL 18のCREATE FUNCTIONドキュメントは、信頼できないスキーマをsearch_pathから外すこと、新規関数に既定で与えられるPUBLICの実行権限を取り消して必要なロールだけへ付与することを求めています。stored functionを唯一の書き込み口にするなら、その入口自体の権限設計が崩れていないかを先に試したいところです。

完了判定もワーカーから切り離します。作業用ブランチを作ったワーカーとは別のロール、できれば異なるモデル系統の検証者が、作業後に発行された検証バンドルを使ってクリーンな環境で判定します。さらに次回の定期観測が緑になるまでconfirmedにしないことで、パッチ作成時の一度きりの成功と、環境が望ましい状態へ戻ったことを分けます。

この検証経路も、2026年8月15日時点では計画段階です。過去の監査で独立センサーが45夜連続で動き、実際の欠陥を見つけたことと、新しいcampaign方式が修正から再確認まで閉じられることは、別の証拠として扱う必要があります。

LISTEN/NOTIFYは台帳の代わりではなく起床ベルにする

状態変化のたびにワーカーをすぐ起こしたくなると、LISTEN/NOTIFYが候補に上がります。ただしLISTENの公式仕様では、購読登録はセッション終了時に消え、購読開始時には競合条件があるため、先にLISTENをコミットしてからDB状態を読み、その後の通知を受ける手順が示されています。

つまり、通知だけを記憶として扱うと、再接続時の空白を埋められません。テーブルを正本にし、定期reconcilerが取りこぼしを回収し、NOTIFYは待ち時間を短くするヒントとして使う方が役割を分けやすいと分かります。NOTIFYの仕様も、大きな情報はテーブルへ置き、通知ではレコードのキーを渡す方法を案内しています。

一方、永続実行そのものを提供する専用基盤もあります。Temporalの公式ドキュメントは、クラッシュやネットワーク障害の後もワークフローを中断地点から再開することを製品の中心機能にしています。すでに複雑なワークフロー、耐久タイマー、複数サービス間の回復を必要としているなら、PostgreSQL上で同等の仕組みを自作する前に比較したい選択肢です。

Looperの判断は、1台のマシンで外部CLIを動かす夜間規模の仕事に、別の状態を持つシステムを増やさないというものです。これはPostgreSQLが常に専用エンジンより優れるという主張ではなく、現在の故障モデルと運用範囲に合わせた選択です。

1種類のcampaignで停止・拒否・再開を先に証明する

再設計を評価するなら、コンポーネント数や生成した文書の量ではなく、仕事が閉じるまでの故障経路を試します。一次ソースがPhase 1Aとして計画している最小セルは、1種類のcampaign、1つの実行席、1つの監視対象、1つの検証バンドル、1つの権限プロファイルに絞られています。

予定されているドリルは具体的です。故障を注入すると人手なしでcampaignが開くこと、最初の試行を失敗させると2回目が別の方法を取ること、実行中のワーカーを落とすとリースが回収されること、不正なパッチは拒否され正しいパッチは通ること、禁止された書き込みは防止され記録されることを順に確かめます。最後に、次回の定期観測が緑になって初めて完了です。

さらに7日連続で人の介入なしに検証済みの完了を作る試験も計画されています。仕事が0件のまま介入も0件なら成功ではなく「十分に試されていない」と判定するため、活動量ではなく、対象となる仕事に対して何件を閉じられたかを測れます。

この試験はまだ実行されていません。現時点で採用できるのは完成済みアーキテクチャではなく、何を証明すれば次へ進めるかという実験設計です。

PostgreSQLが「システム」になるのは全経路が台帳を通るとき

冒頭の問いへの答えは、エージェントの会話履歴を長く持たせることではありません。未完了の目的、所有権、試行、証拠、次の起床条件を耐久データにし、どのワーカーが消えても別のワーカーが続けられるようにすることです。

PostgreSQLは、行ロック、トランザクション、ロール、関数、トリガーを同じ場所で組み合わせられるため、その中心になれます。ただし、全ワーカーが台帳を迂回できず、検証結果が状態遷移へ結び付き、外部副作用に別の冪等性と柵がある場合に限ります。

エージェントを交換可能にするだけでは自律システムは完成しません。仕事が残り、失敗が次の異なる試行を起こし、独立した証拠で閉じるところまで続いて、初めてPostgreSQL中心の設計が実務上の意味を持ちます。

出典

• Title: Payal Singh: The agent is not the system. Postgres is.
• URL: https://postgr.es/p/9sm