AIエージェントのプロセスが止まったとき、対話履歴だけでは外部サービスの処理がどこまで進んだか分からない。Pi Durableは、対話、モデルの応答、ツール呼び出し、アプリケーション状態を保存し、未完了の仕事を再開するための実験的なエージェント用ハーネスだ。

開発元の説明では、Pi DurableはPiのコーディングエージェントそのものではなく、どの場所でも動くエージェントアプリケーションを組み立てるフレームワークである。導入を判断するには、復元できる状態と、復元後に重ねてはならない外部操作を分けて見る必要がある。

中断で失われるのは対話だけではない

会話の履歴を読み戻せても、外部操作の完了状態までは確定しない。エージェントがクラウド資源を作った直後に停止し、資源IDを書き込む前に再起動した場合、履歴だけを見た新しいプロセスは「作成済み」「未作成」「作成後に応答を失った」のどれかを判定できない。

保存対象は三つに分けると整理しやすい。対話記録は利用者の入力、モデルの応答、ツールの結果を残す。タスク状態は処理の段階、待機中の条件、再試行の状態を持つ。アプリケーション状態は、計画、チケット、作業ディレクトリーなど、エージェントの仕事を表すデータである。これらが別々に更新されると、内部の記録と外部の実態にずれが生じる。

Pi Durableは、タスクを次の段階へ進める前にチェックポイントを保存する設計を採る。公式READMEは、対話、モデル処理、ツール呼び出し、アプリ状態をストレージへコミットし、プロセスが途中で止まった場合は同じストレージを開いて処理を続ける仕組みを説明している。これは内部状態の整合性を高める仕組みであり、外部サービスの取引を巻き戻す機能ではない。

チェックポイントと再開の流れ

再開の前提は、新しいプロセスが同じ永続ストレージと同じ拡張機能を使うことだ。公式の導入例は、SQLiteファイルを開いてハーネスを起動し、resume()で前のプロセスが残した処理を再開する流れを示す。メモリー上のストレージは試験には向くが、プロセスが終われば状態も消える。

公式READMEに示された保存方式には、メモリー、SQLite、JSONLがある。SQLiteは一つのデータベースファイルに保存し、JSONLはディレクトリー内の追記型ファイルを使う。JSONLは履歴全体をメモリーにも保持するため、長時間動くエージェントではSQLiteを選ぶという説明がある。どの方式でも、保存先のバックアップ、同時利用、アクセス権、障害時の復旧は導入側の設計になる。

モデルの応答が途中で切れた場合は、再起動後にリクエストを送り直し、途中までの応答を中止済みとして履歴に残す。送信に同じrequestIdを使えば、再送時に既存の提出を探せる。これによりフレームワーク内の二重提出を抑えられるが、モデル提供者や外部APIの処理が一度だけ実行される保証とは別の話である。

中断したプロセスが同じ永続ストレージを開き、モデル処理とツール処理を分けて再開する流れ（イメージ）

ツールの再実行は安全性の宣言で分かれる

Pi Durableは、すべてのツールを自動でやり直す設計ではない。ツールの意図は実行前に保存され、開発者がreplay: "safe"と指定したツールだけが中断後に再実行される。読み取りや検索は再実行を設計しやすい一方、通知、決済、削除、デプロイは同じ処理を二度行う危険がある。

安全性の判断は、ツールの名前ではなく外部側の状態で行う。例えばデプロイを実行したが応答を受け取る前にプロセスが止まった場合、再開時に同じ版をもう一度出すのか、まず外部の実行履歴を照会するのかを決めておく必要がある。冪等キー、タスクIDによる重複排除、結果照会、承認待ちを組み合わせても、相手側APIがどの識別子を受け付けるかは個別に確認する。

再実行しないツールでは、保存済みの出力と中断状態をモデルへ返し、次の判断を委ねる。これは停止後の調査余地を残すが、モデルの判断だけで外部操作の重複を防ぐものではない。高い費用や対外的な影響を伴う操作には、人の承認と監査記録を置く設計が必要になる。

一般的なエージェント実装との違い

対話履歴を中心にした実装では、再起動後にアプリケーションが履歴を読み、タスクの進行状況と外部状態を自分で照合する。Pi Durableは、タスク、対話、型付きのJSON文書を一つのコミットの単位に置き、未完了タスクのスケジューリングも担当する。

比較点対話履歴中心の実装Pi Durable
主な保存対象メッセージと任意のアプリデータ対話、モデル処理、ツール、文書状態
再起動後アプリが履歴を読み、次の処理を判断同じ保存先を開き、未完了タスクを再開
ツール中断時再試行や照会の実装が必要安全な再実行か、中断結果の通知かを指定
残る責任状態照合、重複排除、復旧外部副作用、保存先、版の互換性、運用

この差は、既存のキューやワークフロー基盤が不要になることを意味しない。数秒で終わり、入力を再取得でき、やり直しても副作用がない仕事なら、単純なキューと再試行で足りる場合がある。数時間の待機、人工承認、複数段階の処理、再実行コストが大きい外部操作がある場合に、永続化タスクの導入効果を測る価値が出る。

日本ではどうなる

日本での取得先は、公式READMEが示すnpmパッケージとGitHub上のソースである。READMEにはnpm install @earendil-works/pi-durable @earendil-works/pi-ai @earendil-works/chordという導入方法が記載されている。日本語版の販売価格、国内代理店、法人向けサポート料金を示す公式資料は本稿の執筆時点で確認できないため、導入費を円換算したり、日本向けの無料枠を断定したりはできない。実際の費用は、パッケージそのものの条件だけでなく、利用するモデルの料金、実行環境、ストレージ、監視、バックアップで決まる。

法規面では、Pi Durableを使っただけで特別な日本の認証が発生するとは確認できない。ただし、エージェントの対話、チケット、顧客情報を保存するなら、個人情報保護委員会が公開する個人情報保護法と関連ガイドラインを確認し、保存する項目、利用目的、アクセス権、委託先、国外のサービスへの送信、削除方法を整理する必要がある。クラウドの所在地だけで適否が決まるわけではなく、実際のデータフローと契約条件を確認する作業が先になる。

国内事例については、Pi Durableを日本の複数企業や行政が本番運用したと裏付ける公的資料を本稿では確認できていない。日本で試す場合は、社内の個人情報を入れない検証データから始め、SQLiteまたはJSONLの保存先、モデルAPIへの送信、ツールの権限、障害時の復旧を記録する。正式採用の判断は、npmやGitHubの現行版、ライセンス、依存パッケージ、提供元の変更履歴を確認した後に行う。

導入前に実施する故障演習

機能紹介を読むだけでは、復旧後の一貫性は分からない。まず一つの業務を選び、保存すべき対話、タスク段階、アプリ状態、外部操作を表にする。次に、モデル生成中、読み取りツールの実行中、外部書き込み後の応答前、ストレージ障害の四つの地点でプロセスを止める。

各演習では、再開後のタスクが一度だけ進んだか、外部サービスに重複処理がないか、利用者が正しい状態を取得できるかを記録する。ツールの入力形式や拡張機能名を更新した場合は、旧タスクを新しいプログラムが読めるかも確認する。公式READMEが実験的APIと明記している以上、バージョン固定、更新差分の確認、問題時の切り戻しを試験項目に含めるべきだ。

評価の結論

Pi Durableを評価するときの出発点は、「エージェントを永続化したい」という抽象的な要望ではない。中断すると何が失われ、再開後にどの外部操作を重ねてはならず、誰が照合や停止を担うのかを先に決めることである。

保存対象が対話だけなら既存の履歴管理で足りる可能性がある。処理が長く、段階をまたぎ、同じ作業を最初からやり直せないなら、Pi Durableのチェックポイントとタスク管理を小さな検証にかける意味がある。最終判断は、対象環境での復旧結果、外部サービスの冪等性、保存データの管理、実験的APIを追う運用負担で決める。

よくある質問

Pi DurableはPiのコーディングエージェントそのものか
違う。開発元は、Pi Durableをエージェントアプリケーションを構築するフレームワークと説明し、Piのコーディングエージェントを置き換えるものではないとしている。

再起動すればすべてのツールが再実行されるか
再実行されない。開発者が安全と指定したツールだけが再開時に実行され、それ以外は中断状態と保存済み出力をモデルへ返す。

日本向けの価格は決まっているか
公式資料で日本向け価格は確認できない。パッケージ、モデルAPI、実行環境、ストレージの費用を分けて、現行の提供条件を確認する必要がある。

正式な本番標準として使えるか
判断できない。公式READMEが実験的APIと明記しているため、対象の保存方式、ツール、障害条件で復旧演習を行い、版の更新と切り戻しを含めて評価する必要がある。