ピ・デュラブル

元記事: 2026年10月2日原文(earendil.com)

概要

Earendil と Piコミュニティ が Pi 1.0 をリリース新たに Pi Durable という耐久性・可搬性に優れた実験的パッケージも同時発表 Pi Durableは長期間稼働・障害耐性・多地点操作などを実現するハーネス複数人・複数会話・柔軟な拡張性をサポート Pi Durableの設計思想や利用例も詳細に解説

Pi 1.0とPi Durableの発表

Pi 1.0 のリリースによる安定基盤の提供
Pi Durable の同時発表、長期間・どこでも動作するエージェントを想定
Pi Durableは Pi coding agent の置き換えではなく、より広範なエージェントアプリケーションのフレームワーク
Earendil は多様な利用ニーズに応えるためPi Durableを開発
Pi Durableの特徴：どこでも動作、複数会話・複数人対応、障害耐性、柔軟な拡張性

ハーネス（harness）とは

ハーネス ＝ストレージ＋複数の大規模言語モデル会話を並列実行するための仕組み
モデルが呼ぶツールや、その実行環境も提供
会話履歴（トランスクリプト）を保存し、エージェントの状態も管理
ツールの実行環境はローカルPC・リモートVM・インメモリサンドボックス等、会話ごとに切替可能
Pi Durableのソースコードは約15,000行で、エージェントが理解しやすい設計

Pi Durableの特徴と利用例

どこでも長時間稼働 ：JavaScriptランタイムがあれば動作
- メモリ、SQLite、JSONLストレージを標準搭載
- SQLite/JSONLはNode API非依存、BunやCloudflare Durable Objectでも動作
- ストレージインターフェースは小さく、独自バックエンドも容易に実装可能
- ストレージは1プロセスが所有し、他クライアントはアタッチ
- アクティブな会話履歴はモデルのコンテキストウィンドウで自動圧縮
柔軟な実行環境 ：ツールごとにローカル・リモート環境を選択可
- Node実行環境を標準搭載
- 会話ごとに異なる作業ディレクトリ、環境構築が可能
障害耐性 ：プロセス死後も再開可能
- 各タスクは実行前にチェックポイントを保存
- プロセス死後、新プロセスが未完了タスクを検出し再開
- モデルリクエストやツール呼び出しも安全に再実行・中断通知
- サブエージェントも数行で実装可能
複数会話の同時実行 ：1ハーネスで多数会話を並列処理
- 会話のフォークや親履歴の継承が可能
- Slackのチャンネル・スレッドのような構成も容易
- 会話ごとに独自エージェント設定（モデル・ツール・作業ディレクトリ等）を保持

拡張性とプラグイン

エージェントの機能は全てプラグイン化可能
- 拡張（Extension）はプロンプトセクション、ツール、フック、タスクのバンドル
- レジストリにインストールし、会話ごとに利用拡張を選択
- システムプロンプトは拡張のセクションを結合し毎回再構築、変更履歴も記録
- モデルが途中でプロンプト・ツール変更に対応していれば、差分のみ送信
ツールの耐久性
- 各ツール呼び出しは耐久タスクとして管理
- クラッシュ後の再実行可否をツールごとに設定
- 会話ごとのツールセット変更も容易（例：検索は可・デプロイ不可）
ツールはハーネスAPIを利用可能
- ドキュメント操作、タスク・会話の開始、他会話との通信も可能
- サブエージェントや複雑なフローも数行で実装

まとめと今後

Pi Durable はPi coding agentの原則（ミニマリズム・可塑性）を継承
Pi Durable上で得た知見はPi coding agentにも還元される設計
エージェント開発の新たな基盤として、Pi Durableの活用・フィードバックをコミュニティに呼びかけ

関連情報: Pi 1.0 - https://news.ycombinator.com/item?id=49926069

提供: ハクソク · 要約更新: 2026年10月2日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

Piが耐久性のあるエージェントハーネスを作ってるのを見るのはすごくクールだね。自分もこの分野で結構前から開発してるけど、すごく面白いイノベーションの場所だよ。マシン上でのコーディングエージェントほどの盛り上がりはないけど、主要なプレイヤーはみんなこの分野で製品を作ってるんだ。LangChain Deep Agents、Vercel Eve、OpenAI Agents API、Anthropic Managed Agentsとかね。主な理由は、1)「耐久性」があって、無人で長時間動かすのが簡単で、リカバリーやモニタリングも実装しやすいこと、2) ハーネスとコンピュートを分けることで安全性とスケーリングの利点があること、3) マルチプレイヤーにしやすいことだね。

└

ここはハッキングするのにすごく面白い場所だよ。よく理解された問題だけど、いろんな複雑さがあるからね。最終的なデザインにたどり着くまでにどれだけの初期デザインを試したか数え切れないよ。もっと学ぶことがあっても驚かないな。

ソースコード全体はテストなしで約15,000行で、GPTだと約150,000トークン、Claudeだと約250,000トークンになるんだ。トークン数でこんなに違うの？

└

いや、ラボのトークン化スキームについて誰かを煽らない方がいいよ（笑）

└

いくつかのデルタは新しい感じだね。https://openrouter.ai/blog/insights/opus-47-tokenizer-analys...

いいね！自分もPi用にこれのバージョンを作ったけど、単に置き換えられるか楽しみだな（笑）

素晴らしい！でも、耐久性のあるアプリケーション状態がJSONドキュメントだけに制限されてるのは残念だな。外部ストアと会話状態を同期できるようなアウトボックスパターンを実装する統合的な方法があればいいのに。

└

もう（なんとなく）それをタスクを通じてできるよ（エージェントの雑な部分はごめん、深夜で長い一日だったから）： const SyncToPostgres = defineTask({ kind: "app.sync-postgres", version: 1, initial: () => ({ phase: "send" }), phases: { send: async (task, runtime, context) => { const entry = await runtime.read(/* the entry */); await postgres.upsert("messages", { id: task.input.entryId, ...entry }); // idempotent by id await runtime.commit(() => ({ status: "terminal", outcome: { status: "completed" } }), context); }, }, }); await root.commit(async (tx) => { const id = await tx.entry(AssistantEntry, answer); await tx.createTask(SyncToPostgres, { entryId: id }, { ownership: { kind: "conversation" }, background: true }); }, context); ルート会話でのコミットはトランスクリプトから最後のエージェントの回答IDを取り出して、Postgresに同期するタスクを耐久的にスケジュールするんだ。タスク内では、IDで回答を取得して、Postgresに冪等的に送信する。ここで欠けているのは、基本的に各コミット内で実行されるフック、つまりアウトボックスの書き込みが状態変更と原子的に行われ、順序付きで配信されるようなものだね。あとは耐久性のある変更フィードとカーソルもあればいいな。意見ありがとう！

超面白いね。考え中の質問がたくさんある…例えばサンドボックス（持ち込み式っぽいね）。何かポリシーエンジンがあればいいな… https://github.com/NVIDIA/openshell との統合とか、拡張機能の形で？それに、耐久性の約束のほとんどがJSONドキュメントをローカルに永続化して、SQLiteモードでもメモリに保持するデータを最小限に抑えることから来てるのが見えるね。これは理解できるけど、JSONLベースのイベントストアに依存したプロセスでの実験では、I/Oの摩擦を避けるためにメモリ内に保持する方が好きになったんだ。単純な.dbファイルを永続化する方がいいって思うのはおかしいかな？

マルチユーザー機能が一番好きだな。これでリモートコントロールツールを作るのが楽になるはず。TUIがアクティブなインスタンスでACPが使えないのをなんとかしなきゃいけなかったから。

みんな、この無限に動くエージェントを何に使ってるの？

└

一例として、いくつかのcronジョブを使って、異なるプロジェクトを監視してるんだ。Telegramのクローエージェントを通じて通知してくれる。メッセージが来たら、その会話の中で問題を解決するように頼むことができるよ。

Hacker Newsで議論の続きを見る