日常の開発業務において Claude Code や Cursor などのコーディングエージェントを活用するエンジニアが増えるにつれ、実務運用の現場ではより泥臭い課題が浮き彫りになってきました。数時間以上に及ぶ自律タスクの途中でネットワーク切断や API レート制限によってプロセスが停止し、会話は再開できても、実行途中だった作業の続きからは戻れない「クラッシュ時の状態喪失」。そして、Model Context Protocol（MCP）を通じて連携ツールを増やすたびにシステムプロンプトが肥大化し、プロンプトキャッシュが無効化されて API コストとレイテンシが跳ね上がる「コンテキスト消費問題」です。

2026年10月1日、これらの構造的課題に対して極めて明快な設計解を提示するオープンソースソフトウェアが正式リリースされました。Earendil より公開された AI エージェント基盤 「Pi 1.0」 と、同時に公開された長時間実行向けの実験的パッケージ 「Pi Durable」 です1。

Pi 1.0 とは、ミニマリズムと「硬質化（hardened）」を設計思想に掲げる MIT ライセンスのオープンソース AI エージェント基盤（ハーネス）です。そして Pi Durable とは、SQLite や JSONL によるステート永続化と自動コンパクションを備え、プロセスクラッシュや長時間タスクの中断があっても最後のチェックポイントから再開できる、長時間動くエージェントアプリケーションを組み立てるための基盤（npm パッケージ）です。

以下では実機での検証は行わず、公式発表・技術ドキュメント・公開コードの一次情報の整理に徹して、Pi 1.0 の動的ツール実行機構「Codemode」と、Pi Durable が提示する約 15,000 行のハーネスアーキテクチャを解剖します。

提供ステータスと名称に関する注意
  • Pi 1.0: 2026年10月1日に GA（一般提供）リリース。週次数十万人規模のアクティブ利用実績を持つオープンソース基盤（MIT ライセンス）12。
  • Pi Durable: 長時間タスクの耐久実行を目的とした実験的パッケージ（Experimental、MIT ライセンス）3。
  • 名称に関する注意: 旧 Inflection AI が提供していたパーソナル対話型 AI「Pi」とは全く無関係のオープンソース開発エージェント基盤です。

ターミナル単発実行と MCP ツール肥大化が抱えていた限界

新機能の革新性を理解するために、まずは従来のコーディングエージェントや MCP 連携が直面していたアーキテクチャ上のボトルネックを整理します。

長時間自律タスクにおけるクラッシュと状態喪失

従来のコーディングエージェントの多くは、単一のターミナルセッションやオンメモリのプロセス内で動作しています。そのため、長時間の自律ループを実行している最中にマシンのスリープ、コンテナの再デプロイ、メモリ不足（OOM）、ネットワーク切断、あるいは LLM プロバイダーのレート制限などでプロセスが落ちると、実行途中だったツール呼び出しや作業の途中状態は失われます。会話履歴を保存して後から再開できるツールでも、再開できるのは会話であって、中断した作業の続きではありません。

プロセスが停止した場合、開発者はターミナルのログを目視で遡り、どこまで作業が進んでいたのかを推測しながら、手動で再指示を出さなければなりませんでした。長時間自律的に動作する信頼性の高いエージェント基盤を構築する上で、プロセスクラッシュからの復帰機能の欠如は最大の障壁となっていました。

全量スキーマダンプによるコンテキスト消費とキャッシュ無効化

ツール連携の標準プロトコルとして登場した MCP は、エージェントエコシステムの拡張に大きく貢献しました。しかし、多くのハーネスにおける MCP 実装は、利用可能な全ツールの JSON Schema をシステムプロンプトへ常時ダンプする設計を採用していました4。

このアプローチには、運用上無視できない 3 つの深刻な弊害が存在します。

  1. プロンプトキャッシュの無効化とコスト高騰: ツール定義が数万トークンに達すると、ツールセットの僅かな変更によってプロンプトキャッシュ全体が破棄され、毎ターンの API 呼び出しコストと入力レイテンシが跳ね上がります。
  2. モデル推論精度の低下: コンテキストウィンドウがツール定義スキーマで圧迫され、肝心のコードコンテキストや開発者の指示が埋もれてしまいます。
  3. 中間データのコンテキスト流出: ツールを実行するたびに「LLM 呼び出し → ツール実行 → 結果を LLM に返送」という往復が発生し、巨大な JSON レスポンスや中間テキストがすべて会話履歴（コンテキスト）に蓄積され、あっという間にコンテキスト上限を迎えてしまいます。

Pi の開発陣が初期に「Pi does not support MCP」と表明し、安易な MCP サポートを拒絶していたのは、まさにこの「全量ダンプによるトークン肥大化」という設計上の欠陥を危惧していたためでした4。その後、MCP の仕様自体が改善されたことと、後述する Codemode と組み合わせれば従来の弊害の多くを避けられると判断したことから、Pi は MCP をコアの機能として取り込みました4。

ハーネスの4大要素分離と「自己可塑性」がもたらすパラダイムシフト

最初に両者の関係を整理しておきます。Pi 1.0 は pi コマンドで起動するコーディングエージェント（TUI）とそれを支えるツールキットで、Codemode や Virtual Models はこちらの新機能です。一方の Pi Durable は、Pi 本体を長時間実行向けに作り変えるのではなく、別の実験的パッケージとして切り出された、長時間動くエージェントアプリケーションを組み立てるための基盤で、npm から自分のアプリケーションに組み込んで使います1。公式発表は、pi の TUI そのものでクラッシュ復帰が使えるかどうかには触れていません。

そのうえで両者は、エージェントを取り巻く実行基盤──すなわち「ハーネス」の責務境界を定義し直すことで、前節の課題に応えようとしています。

ミニマリズムと「硬質化（hardened）」の設計思想

Earendil は Pi 1.0 の発表で、Pi を「硬質化（hardened）された、ミニマルで拡張可能な」エージェントハーネスと位置づけ、ミニマルであることを守り続けると述べています1。

Mario Zechner が創始した当時の Pi は、組み込みツールを read, write, edit, bash の 4 つのみに絞り込み、業界最短クラスの極小システムプロンプトで最大の性能を引き出すミニマリズムを徹底していました5。その後、Mario Zechner が Armin Ronacher らの Earendil に合流して共同開発体制ができ6、利用者からの数ヶ月分のフィードバックをもとに改善と硬質化を重ねて Pi 1.0 に至りました1。

ハーネスを定義する4つの独立した責務境界

4 大要素の定義は Pi Durable の記事によるものです。Pi Durable では、エージェントを単なる「プロンプトと LLM のループ」として捉えず、堅牢な実行基盤（ハーネス）として以下の 4 大要素へ明確に責務を分離しています3。

  1. Storage（ストレージ）: ハーネスの土台となる永続化層。Memory, SQLite, JSONL の実装が同梱されている。
  2. Machinery（機械部）: 1 つ以上の会話を LLM と並行して動かすための仕組み。モデル呼び出しからツール実行まで、ハーネスが動かすものはすべて「タスク」として扱われる。
  3. Tools（ツール）: モデルが呼び出すツール。どのツールを使えるかは会話ごとに決まる。
  4. Execution Environments（実行環境）: ツールが実際に動く場所。手元のマシン、リモート VM、インメモリのサンドボックスのいずれでもよい。

当ブログの過去記事 AGENTS.md による階層的コンテキスト制御 では、巨大なプロンプトによるモデルの混乱を防ぐために指示書を階層分割するアプローチを解説しました。Pi Durable が提示するハーネス設計は、この考え方をさらに一歩進め、プロンプトの工夫だけでなく、ランタイムレベルでストレージと実行環境を明確に切り離す「硬質化された責務分離」の重要性を示しています。

15,000行がもたらす Supermalleability（自己可塑性）

Pi Durable の極めて特徴的な点は、テストコードを除くコードベース全体が約 15,000 行（ストレージ実装は約 3,000 行）という圧倒的なコンパクトさで実装されていることです3。

このコード量は、各モデルのトークナイザで換算すると GPT 系モデルで約 150,000 トークン、Claude 系モデルで約 250,000 トークンの最悪値見積もりに相当する規模です3。

公式記事はこれを「最悪の場合」の値とし、実際にエージェントが全体を読む必要はまれで、約 3,000 行のストレージ実装は通常読み飛ばせると補足しています3。エージェント自身がハーネスを理解できる規模に保つ──Pi Durable の記事は「Pi のすべてと同様に、エージェントが理解できるように作られている」と述べています3。なお Pi 1.0 の発表は、Pi をエージェントアプリケーションを組み立てるための「supermalleable（極めて改変しやすい）」土台と表現しています1。

最小構成での起動と Codemode によるツール実行の革新

Pi 1.0 は、対話型コーディングエージェントとしての最小構成を保ちながら、MCP の課題を解消する動的コード実行機構「Codemode」を導入しました。

Pi 1.0 のインストールと起動

Pi 1.0 は公式のシェルスクリプトで導入できます。Node.js 22.19 以上が要求されます2。

# macOS / Linux でのインストール
curl -fsSL https://pi.dev/install.sh | sh

# インストール確認と TUI 起動
pi --version
pi

インストール後、ターミナルで pi コマンドを実行すると、フルスクリーンの対話型ターミナル UI（TUI）が起動します1。Codemode は MCP を設定すると自動で読み込まれ、既定のツールとして設定に加えることもできます4。

サンドボックスと動的オーケストレーション

Codemode は、全ツールのスキーマをプロンプトに常時ダンプするのではなく、ハーネスのイベントループ側に組み込まれた軽量 JavaScript サンドボックス上で、モデルにコード（スクリプト）を書かせてツールを実行させるアーキテクチャです4。

Hacker News のスレッドに投稿された開発者本人とみられるコメントによると、このサンドボックスの実装には WebAssembly バイナリとして配布可能な QuickJS が採用されています7。

モデルはツールを 1 つずつ逐次的に呼び出すのではなく、「必要なツールを動的に呼び出し、JavaScript の非同期ループやワーカーで並列処理し、フィルタリングや集計を行った最終結果だけを LLM に返す」スクリプトを生成してサンドボックス内で一括実行します4。

では、スキーマを常時渡さないなら、モデルはツール名や引数の形をどう知るのでしょうか。公式記事が説明しているのは、ツールごとに「遅延ロード（deferred）」にするか「Codemode 専用」にするかを設定できる必要があったこと（通常の MCP 拡張では、そのためのメタデータが足りなかった）、そして MCP のツールは説明文やドキュメントから発見できるべきだという考え方までです4。モデルが関数名や引数を実行時にどう参照するのかという具体的な仕組みは、公式記事には書かれていません。

167件の課題を単一ターンで処理した実証パターン

Earendil が公開した実証実験では、この Codemode の真価が克明に示されています4。

題材は、課題管理ツール Linear の MCP サーバーから open な課題 167 件を取得し、非 LLM の分類モデル Jev（コード上は Cloudflare Workers AI 経由の typesafe/jev）を用いて、課題コメントに書き込まれた感情トーンを判定するタスクです。

以下は、公式記事に掲載された、エージェントが Codemode 上で生成・実行したスクリプトです（日本語コメントは本記事で追記したもの。ファイルとして保存するものではなく、Codemode のサンドボックスに渡されるスクリプトです）。

// 1. Linear MCP ツールから open な課題一覧を取得
const { issues } = await tools.mcp__linear__list_issues({
  team: "Pi",
  state: "open",
  limit: 250,
});

// 2. 感情分析モデル（Jev）を取得
const jev = await models.getModelOfType(
  "classifier",
  "cloudflare-workers-ai",
  "typesafe/jev",
);

const questions = {
  frustration: {
    type: "choice",
    instructions:
      "Judge ONLY the emotional tone of the people writing. Ignore how severe the bug is.",
    criteria: {
      none: "Neutral, factual, or friendly, even about a serious bug",
      mild: "Explicit annoyance, impatience, or disappointment",
      high: "Clearly angry, exasperated, sarcastic, or fed up",
    },
  },
};

// 3. 4本のワーカーでコメント取得と判定を並列実行（中間結果は LLM コンテキストへ戻さない）
const results = [];
let next = 0;
async function worker() {
  while (next < issues.length) {
    const issue = issues[next++];
    const { comments } = await tools.mcp__linear__list_comments({
      issueId: issue.identifier,
    });
    const c = await models.classify(jev, { state: { ...issue, comments }, questions });
    results.push({ id: issue.identifier, title: issue.title, ...c.answers.frustration });
  }
}
await Promise.all([worker(), worker(), worker(), worker()]);
store("frustration", results); // 判定結果を Codemode 側に保存（課題を再取得せずに後から参照できる）

// 4. 集計結果のみを返却
const score = (r) => r.probabilities.mild * 0.5 + r.probabilities.high;
const counts = {};
for (const r of results) counts[r.choice] = (counts[r.choice] ?? 0) + 1;
const flagged = results.filter((r) => r.choice !== "none");
flagged.sort((a, b) => score(b) - score(a));

return {
  total: results.length,
  counts,
  flagged: flagged.map((r) => `${r.id} ${r.title}`),
};

公式記事に掲載された実行ログ（抜粋。flagged は原文の11件から先頭3件に省略）:

... (331 earlier calls)
✓ mcp__linear__list_comments {"issueId":"PI-4714"} 255ms
✓ mcp__linear__list_comments {"issueId":"PI-3200"} 354ms
✓ models.classify cloudflare-workers-ai/typesafe/jev 756ms
✓ models.classify cloudflare-workers-ai/typesafe/jev 750ms

{
  "total": 167,
  "counts": {
    "none": 156,
    "mild": 11
  },
  "flagged": [
    "PI-7740 TUI after /reload does not follows custom tool's re…",
    "PI-9566 context size defaults to 128k despite the real size…",
    "PI-10031 Pi sporadically stuck in \"Working...\" when thinking…"
  ]
}

ログには ... (331 earlier calls) に続いて4件の呼び出しが表示されており、合計は 335 回です。これは課題一覧の取得 1 回、167 件分のコメント取得 167 回、感情分類 167 回の合計と一致します4。

従来の MCP であれば、335 回もの往復履歴と全コメント本文がすべて LLM のコンテキストを圧迫していたはずです。Codemode では、4 本の並列ワーカーによる生データの取得と感情判定がすべてサンドボックス内で完結し、LLM には最終的な集計結果（none 156件、mild 11件、high 0件。ラベル付与等の副作用は伴わない）という軽量な JSON のみが返却されます4。公式記事はこれを「コンテキストを一切無駄にせずに（without wasting any context at all）」行えると説明しています4。

Pi Durable によるステート永続化とコンパクションの仕組み

Pi 1.0 本体の軽量性を維持する一方で、長時間の会話やタスクの耐久実行を可能にするために設計されたのが、実験的パッケージ「Pi Durable」です。

SQLite / JSONL ストレージとオンメモリ・ワーキングセット管理

Pi Durable は、@earendil-works/pi-durable, @earendil-works/pi-ai, @earendil-works/chord というパッケージ群で構成され、npm からインストールします1。

npm install @earendil-works/pi-durable @earendil-works/pi-ai @earendil-works/chord

ストレージアダプタとして Memory, SQLite, JSONL を標準サポートしています。SQLite および JSONL の実装コードは Node.js の API を使っていないため、小さなアダプタを用意すれば、Bun や Cloudflare Durable Objects といった Node.js 以外の JavaScript ランタイム上でも動作させることができます3。

また、SQLite 上で動作する際、ハーネスはすべてのトランスクリプトをメモリに展開しません。アクティブなトランスクリプト、稼働中のタスク、保留中の投入（submission）のみをオンメモリの「ワーキングセット」として保持し、残りはディスク上に留めます。アクティブなトランスクリプトは後述するコンパクションによってコンテキストウィンドウ内に収まるため、数万メッセージに及ぶ会話でもメモリに無理なく収まると説明されています3。

チェックポイントと resume() によるクラッシュ復帰

Pi Durable では、モデル呼び出しからツール実行に至るまで、ハーネスが実行するすべての動作が「タスク（task）」としてモデル化されています3。

各タスクはステップごとにチェックポイントをストレージに保存してから次に進みます。そのため、プロセスが不意にクラッシュしても、新しいプロセスが同じストレージを開いて harness.resume() を呼び出すだけで、未完了タスクが最後のチェックポイントから再開されます3。

タスク投入時にクライアント側が付与する requestId（例: "job-42"）により、クラッシュ後の再送時でも二重実行が防止され、既存の実行結果が返却されます（submission exactly-once）3。

さらに、クラッシュ復帰時のツール実行ポリシーもきめ細かく制御されます。ツール定義で replay: "safe" が指定されているツール（公式の例では読み取りだけを行うツール）は再実行されますが、安全性が保証されていないツールが中断された場合は再実行されず、中断された旨がモデルに通知されて次の判断を仰ぐ安全設計となっています3。

reserveTokens と backgroundTokens による二段階コンパクション

長時間の自律運用において避けられないのが、モデルのコンテキスト長上限への到達です。Pi Durable では、コンパクション（会話履歴の要約圧縮）自体も独立したタスクとして設計されており、会話を停止させることなくバックグラウンドで並行実行されます3。

二段階のトークン閾値制御は次のように設計されています。

  1. 先行バックグラウンド要約（backgroundTokens: 32768）: コンテキスト使用量が contextWindow - reserveTokens - backgroundTokens（残り 49,152 トークン）を超えた時点で、バックグラウンドワーカーが先行して会話履歴の要約を開始します。メインの対話ループはブロックされません3。
  2. 同期待機枠（reserveTokens: 16384）: コンテキスト使用量が限界枠（contextWindow - reserveTokens）に達した場合、次のリクエストは要約の完了を待ってから送信されます。それでもプロバイダーにリクエストが長すぎると拒否された場合は、コンパクションしてから 1 回だけ再試行します3。

以下は、SQLite ストレージを指定し、二段階コンパクションとクラッシュ復帰を構成するハーネスの実装例です。

ファイル: src/durable-harness.ts

import { BACKGROUND_CONTEXT } from "@earendil-works/chord/context";
import { createModels } from "@earendil-works/pi-ai/models";
import { openaiProvider } from "@earendil-works/pi-ai/providers/openai";
import { createRegistry, Harness } from "@earendil-works/pi-durable";
// 実行環境とストレージは Node 用のアダプタを使う（ランタイムごとに差し替える構成）
import { NodeExecutionEnv } from "@earendil-works/pi-durable/env/node";
import { openNodeSqliteStorage } from "@earendil-works/pi-durable/storage/sqlite/node";
import { CodingTools } from "@earendil-works/pi-durable/tools";

// すべての呼び出しはキャンセル用のコンテキストを受け取る
const context = BACKGROUND_CONTEXT;
const models = createModels();
models.setProvider(openaiProvider());

const registry = createRegistry();
registry.install(CodingTools); // read, write, edit, bash

const env = ({ cwd }: { cwd?: string }) =>
  new NodeExecutionEnv({ cwd: cwd ?? process.cwd() });

// 1. SQLite ストレージを開き、二段階コンパクションを設定してハーネスを起動
const storage = await openNodeSqliteStorage("./agent.sqlite");
export const harness = await Harness.open(
  storage,
  {
    models,
    registry,
    env,
    settings: {
      compaction: {
        // 使用量が contextWindow - 49,152 を超えたらバックグラウンド要約を先行開始
        backgroundTokens: 32768,
        // 使用量が contextWindow - 16,384 を超えたら、次のリクエストは要約の完了を待つ
        reserveTokens: 16384,
      },
    },
  },
  context,
);

// 2. 起動時に未完了タスクを再開する（公式サンプルでは、クラッシュ後の新しいプロセスが
//    同じストレージを開いてから呼んでいる）
harness.resume();

// 3. ルート会話を取得する（初回使用時に作成され、再起動後も同じ会話が返る）
const root = await harness.root(context);

// 4. タスクを投入する。requestId を付けておくと、クラッシュ後にクライアントが再送しても
//    二重に投入されず、元の投入が返る
await root.submit(
  { type: "input", content: "Fix the flaky login test", requestId: "job-42" } as const,
  context,
);

このコードは公式記事の複数のサンプルを組み合わせたものです。Harness.open に SQLite ストレージと二段階コンパクションの設定を渡し、起動のたびに harness.resume()（引数なし）を呼ぶ構成にしています。前のプロセスがクラッシュしていれば、未完了のタスクが最後のチェックポイントから再開されます3。

defineDoc とアトミックトランザクション

Pi Durable では、エージェントが扱う構造化データ（TODO リストや計画書、チケット情報など）は defineDoc を用いて型付き JSON ドキュメントとして定義されます3。

ドキュメントの更新はトランスクリプトの書き込みと同一トランザクション（api.commit）内で行われるため、「会話履歴は更新されたが状態ドキュメントが更新されていない」といった状態の不整合が発生しません。また、任意の数のクライアントが同じ会話に途中から接続でき、whenBusy: "steer" を付けて入力を送ると、その指示は実行中の作業に現在のツール呼び出しの後から合流します（マルチプレイヤー機能）3。

Virtual Models による計画・実装のモデル分業実践

Pi 1.0 で加わった機能のうち、ここでは「Virtual Models（仮想モデル）」と、会話途中での動的プロンプト・ツール差し替え機能（Mid-conversation system messages）の 2 つを取り上げます。

単一モデル依存からの脱却：タスクフェーズごとの最適配分

コーディングエージェントにおいて、すべての推論工程を単一の高価格フロンティアモデルで実行するのはコスト面・応答速度面で非効率です。複雑な論理設計やアーキテクチャ検討には高い推論力が必要ですが、決まった仕様に基づくコーディングやテストコードの反復生成には、高速かつ安価なモデルが適しています。

router/auto による仮想モデルルーティング

Pi 1.0 で加わったのは、仮想モデルを拡張（extension）として登録できるようにする仕組みです。仮想モデルは、エージェントロジック側からは単一の仮想モデル名（例: router/auto）を参照させ、背後で実際のプロバイダーモデル（Claude や GPT 等）へのルーティングを動的に切り替えます1。

Pi 1.0 公式発表では、Pi 自身が「Claude Opus でアーキテクチャを計画し、GPT でコードを実装し、Jev がフェーズ切り替えを判定する」仮想モデル拡張を自作した実例が紹介されました1。この分業ルーターは標準で同梱されるものではなく、拡張の仕組みを使った作例です。

この作例では、拡張を読み込んだうえでセッション開始時に router/auto を選択すると、計画フェーズでは Claude Opus が思考を担当し、Jev がコード実装フェーズへの移行を検知すると自動的に GPT 6 Luna へとハンドオーバーされます1。拡張として仮想モデルを登録する具体的な API は、公式ドキュメント（pi.dev）で確認してください。

会話途中でのシステムメッセージ動的切り替え

もう 1 つの新機能が、会話セッションの途中でシステムプロンプトや利用可能ツールセットを動的に差し替える「Mid-conversation system messages」です1。

公式発表はこの機能を「トランスクリプトを意識したプロンプトとツールの変更」と説明しています1。Hacker News のスレッドでは、開発者本人とみられるコメントが、会話途中のシステムメッセージとツールセットの変更を「KV キャッシュを保つため」に加えたと述べています7。システムプロンプトやツール定義を書き換えるとプロンプトキャッシュが無効になりやすいため、フェーズの切り替えでキャッシュを捨てずに済むことが狙いだと読めます。キャッシュを保つ具体的な仕組みは、公式記事には書かれていません。

制限事項と既存エコシステムとの使い分け

ここまで見てきたように、Pi 1.0 と Pi Durable はエージェントハーネスとして極めて洗練された設計を備えていますが、導入にあたっては冷静な見極めも必要です。

Pi Durable 採用時のトレードオフと注意点

まず留意すべきは、Pi 1.0 本体は GA（一般提供）として安定しているものの、長時間耐久実行を担う Pi Durable は依然として「Experimental（実験的）」ステータスである点です3。今後のバージョンアップによってストレージスキーマや API インターフェースに破壊的変更が入る可能性があります。Hacker News でも、追加される複雑さに見合う価値があるのかを疑問視する声が出ています8。業務システムの根幹に組み込む場合は、直接の密結合を避け、自社システム側でラッパー層を設けておくことを筆者は勧めます。

また、Pi はターミナル TUI および CLI、または TypeScript ライブラリとしての組み込みに特化しています。VS Code や JetBrains などの統合開発環境（IDE）上でリッチなインライン差分プレビューや GUI 補完を求めるユースケースでは、Cursor や GitHub Copilot のような既存ツールが適しています。

既存エージェント基盤との比較

Pi 1.0 は、完成された商用ツールとは異なり、開発者が自社の要件に合わせてエージェントの挙動を完全に制御・改修できる「硬質化された基盤」として独自の立ち位置を確立しています。

比較項目Pi 1.0 + Pi DurableClaude Code従来の自作エージェントスクリプト
設計思想・位置付け最小主義の硬質化ハーネス・ツールキットAnthropic 最適化の完成品 CLI個別の API 呼び出しループ
コードベース規模テスト除き約 15,000 行（エージェントが読める規模）3非公開（商用ツール）規模は実装次第
MCP ツール実行サンドボックスによる Codemode（並列・集約）4—手動パースまたはライブラリ依存
ステート永続化SQLite / JSONL（チェックポイント復帰）3会話単位で --resume / --continue による再開なし（プロセス終了で消失）
主たる利用形態TUI / CLI / 自社基盤への組み込み13ターミナルでの対話型開発バックグラウンドバッチ処理等

このように、手元で素早くコーディング作業を対話的に進めたい場合は Claude Code などの完成品 CLI が扱いやすいですが、自社システムに組み込む長時間自律エージェントの基盤を設計する上では、Pi 1.0 が提示する 4 大要素分離と Codemode のアーキテクチャは有力な参考になると筆者は考えます。

よくある質問（FAQ）

Q. Pi 1.0 は既存の MCP サーバーをそのまま利用できますか？

A. はい。Pi 1.0 は MCP をコアの機能としてサポートし、MCP を設定すると Codemode が自動で読み込まれます4。従来の全量スキーマダンプではなく、軽量 JavaScript サンドボックス内で動的にツールを実行・集約する仕組みを採用しているため、トークン消費を抑えながら既存の MCP 資産をフル活用できます。

Q. Pi Durable を今すぐ本番運用の業務システムに組み込めますか？

A. 現時点では慎重な検討を推奨します。Pi Durable は MIT ライセンスで公開されているものの、公式に「Experimental（実験的）」と位置づけられており、今後のバージョンアップでストレージ層や API の破壊的変更が行われる可能性があります。本番環境に組み込む場合は、直接依存を避け、自社システム側で抽象インターフェースを設けておくことが賢明です。

Q. 旧 Inflection AI が提供していた対話型 AI「Pi」とは何か関係がありますか？

A. 全く関係ありません。旧 Inflection AI の「Pi」は消費者向けのパーソナルアシスタント AI サービスでしたが、本記事で解説している「Pi 1.0」は Earendil（Armin Ronacher, Mario Zechner）が主導するオープンソースのターミナル型 AI エージェント基盤・開発ハーネスです。

まとめ

Pi 1.0 と Pi Durable の要点は次のとおりです。

  • ハーネスの4大要素分離: エージェントを Storage, Machinery, Tools, Execution Environments の 4 領域に明確に分離し、テストコードを除き約 15,000 行というコンパクトさによって、エージェントが基盤コードを理解・改修しやすい規模（Supermalleability）に保っている。
  • Codemode による MCP のコンテキスト解決: システムプロンプトへの全量スキーマダンプを廃し、JavaScript サンドボックス内でモデルに JavaScript スクリプトを実行させることで、300 回超の大規模な並列ツール呼び出しを単一ターン内で集約・完結できる。
  • Pi Durable によるチェックポイントからのクラッシュ復帰: 全ステップをタスクとしてチェックポイント保存し、プロセス再起動後は harness.resume() で即座に復帰できる。requestId による二重実行防止と、二段階コンパクション（先行バックグラウンド要約と同期待機枠）により、長時間の自律タスクを耐障害性高く実行できる。
  • 自社基盤構築の青写真: Pi 1.0 は単なる完成品ツールではなく、自社独自のエージェント基盤や業務自動化パイプラインを堅牢に構築するための「硬質化されたハーネスの青写真」として極めて高い価値を持つ。

AI エージェントを自社の業務基盤や自動化パイプラインに組み込むためのハーネス設計、トークンコスト削減や耐障害性の向上についてご検討の際は、ぜひ コンタクトフォーム よりお気軽にご相談ください。

Footnotes

  1. Pi 1.0 Earendil、2026年10月1日。2026年10月1日の正式リリースと GA 告知、週次数十万人の利用実績、「hardened」の設計思想、Virtual Models 拡張、Mid-conversation system messages、TUI テーマとフルスクリーン表示、インストール手順（https://pi.dev/install.sh）、Pi Durable を Pi 本体とは別の実験的パッケージとして切り出した経緯、「supermalleable substrate」の表現、Virtual Models の作例（Claude Opus で計画し GPT 6 Luna で実装、Jev が切り替えを判定、router/auto）。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  2. earendil-works/pi Earendil、2026年10月。公式 GitHub リポジトリ、MIT ライセンスの確認、主要パッケージ構成（@earendil-works/pi-coding-agent, @earendil-works/pi-durable, @earendil-works/pi-ai, @earendil-works/chord 等）、Node.js 22.19 以上要件。 ↩ ↩2

  3. Pi Durable Earendil Engineering、2026年10月1日。実験的パッケージ（MIT ライセンス）、ハーネスの4大要素（Storage + Machinery + Tools + Execution Environments）、コード規模約15,000行（ストレージ約3,000行、トークナイザ換算最悪値: GPT 約150k / Claude 約250k トークン）、SQLite/JSONL/In-memory ストレージ、ワーキングセット管理、チェックポイント復帰（引数なし harness.resume()）、タスク投入側 requestId による重複防止、コンパクション設定（reserveTokens: 16384, backgroundTokens: 32768）、状態管理（defineDoc, api.commit）、マルチプレイヤー割り込み（whenBusy: "steer"）、プロバイダー拒否時のコンパクションと1回の再試行。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22

  4. “You Said No MCP!” Earendil Engineering、2026年9月29日。従来の MCP スキーマダンプによるトークン肥大化とキャッシュ無効化への批判、WASM サンドボックスによる Codemode、Linear MCP と Jev による 167 課題（none 156 / mild 11 / high 0）・335 回呼び出しの単一ターン集約実証（ラベル付与なし）、MCP のコア機能化、MCP 設定時の Codemode 自動読み込み、ツールごとの deferred / Codemode 専用設定。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  5. Pi: The Minimal Agent Within OpenClaw Armin Ronacher、2026年1月31日。Mario Zechner による Pi の創始、ミニマリズム原則（組み込み4ツール: read, write, edit, bash）、業界最短クラスのシステムプロンプト。 ↩

  6. Mario and Earendil Armin Ronacher、2026年4月8日。Armin Ronacher と Colin Daymond Hanna による Earendil 設立、Mario Zechner の合流と Pi の共同開発体制の確立。 ↩

  7. Pi 1.0 (Hacker News discussion) Hacker News コミュニティ、2026年10月1日。1,600 ポイント超・500 コメント超の反響、開発者コメントによる QuickJS WASM blob 採用の言及、Claude Code や Codex CLI との比較議論。 ↩ ↩2

  8. Pi Durable (Hacker News discussion) Hacker News コミュニティ、2026年10月1日。460 ポイント超の反響、エージェントのステート永続化とクラッシュ復帰に関する議論、追加される複雑さに見合う価値があるかを疑問視するコメント。 ↩