pi coding agentのWeb UI「pi-web」の仕組みと特徴

ターミナルベースの AI コーディングエージェントを日常的に使い始めると、コード生成のスピードには満足しつつも、周辺の運用面で細かなストレスがたまってきます。過去のセッション履歴をあとから辿りたい、複数プロジェクトを行き来している最中にコンテキストが混ざる、モデルや API キーの切り替えのたびに設定ファイルに戻る、といった具合です。

CLI の軽快さは魅力ですが、履歴を眺めたり、複数ブランチを並行して試したりする用途では、ターミナルだけで完結させるのは必ずしも快適ではありません。とくに Git worktree を活用してブランチごとにチェックアウトを分けたい場合、CLI とエディタとエージェントの状態を頭の中で同期させる負担が増えていきます。

その隙間を埋める OSS が「pi-web」です。pi coding agent 向けに設計されたローカル Web UI で、既存の pi セッションファイルをブラウザから読み込み、閲覧・再開・フォーク・モデルや API キーの管理までを一つの画面で扱えるように整えています。

本記事では、pi-web のリポジトリ基本情報と機能構成、公式ドキュメントに沿った導入手順、Git worktree サポートの仕組み、そして Aider や Claude Code 向けの類似 Web UI との違いを、GitHub 上の README およびリポジトリ内 docs/ の記載に基づいて解説します。動作検証は行わず、あくまで公開ドキュメントの範囲で「pi-web を自プロジェクトに組み込むべきか」の判断材料を整理します。

pi coding agentのWeb UI「pi-web」とは

pi-web は、pi coding agent のセッションをブラウザから操作するための ローカル Web UI です。GitHub 上の agegr/pi-web リポジトリ では、Web UI for the pi coding agent と自己紹介されています。ローカルに保存された pi のセッションファイルを読み込み、Web ブラウザ経由で会話履歴の閲覧・継続・フォークを行える点が特徴です。

pi-webの位置づけ（pi本体との関係）

pi-web はそれ単体で LLM を呼び出したり、コーディングエージェントとして動作したりするツールではありません。あくまで pi coding agent（コアの CLI エージェント）のローカル状態を対象にした Web フロントエンドとして位置づけられています。

pi coding agent 本体は別リポジトリで公開されている @earendil-works/pi-coding-agent（TUI ベースのコーディングエージェント CLI）で、公式サイトは pi.dev です。pi 本体のアーキテクチャや設計思想（最小限の機能をシップし、スキル・プロンプトテンプレ・テーマで拡張する「エージェントハーネス」という発想）については、秋霜堂の別記事Pi coding agentとは｜MCPに頼らず拡張できるTUIハーネスで解説していますので、pi 本体に馴染みがない方はあわせて参照してください。

本記事では pi 本体の解説には深入りせず、「pi 本体のセッションをブラウザから扱う UI コンパニオン」という一点に絞って pi-web を扱います。

リポジトリ基本情報とライセンス

pi-web の GitHub リポジトリ（agegr/pi-web）から取得した基本情報は次のとおりです。

archived / fork のいずれも false であるため、記事執筆時点ではアーカイブされていない現行メンテナンスのオリジナルリポジトリとして扱えます。ライセンスは MIT で、社内利用・商用プロジェクトへの組み込みも含めて条件は比較的緩やかです。ライセンス条項の詳細は各自リポジトリの LICENSE ファイルで確認してください。

言語構成は TypeScript が中心で、リポジトリのファイル構成（app/, components/, hooks/, lib/, next.config.ts, tailwind.config.ts など）から、Next.js（App Router）と Tailwind CSS をベースにした Web アプリケーションとして構成されていることが読み取れます。

pi-webの主な機能

pi-web の主な機能は、README の「Key features」節にまとめられています。ここでは README の記載に沿って、機能を大きく 4 つのグループに分類して整理します。

セッション運用機能（閲覧・フォーク）

pi-web の中心的な役割は「過去の pi 会話を扱いやすくする」ことです。README では次の 2 点が挙げられています。

• 過去セッションの閲覧・再開: プロジェクトごとに過去の pi 会話をまとめて閲覧し、任意のセッションを再開できる
• セッションのフォーク: 以前のメッセージから続けたり、セッションを分岐（フォーク）させて別方向を安全に試せる

CLI 単体ではスクロール・grep・シェル履歴を頼りに過去会話を辿ることになりますが、pi-web ではプロジェクト単位で会話一覧を UI 上に並べ、そこから続きを再開したり、任意の時点からフォークして別方針を試したりできます。「一度うまくいきかけた分岐を残しつつ、別方向も並行して探索したい」という探索的な作業に向いた設計です。

プロジェクト連携機能（ファイル閲覧・worktree切替）

エージェントとの対話中も、プロジェクトのファイルを並行して確認したい場面は多くあります。pi-web はこの用途を意識し、次の機能を備えています。

• プロジェクトファイルの並行閲覧: エージェント作業中でも、ソース・画像・音声・PDF プレビューをサイドバーから確認できる
• Git worktree の切替: サイドバーから Git worktree を切り替え、複数ブランチのチェックアウトを行き来できる

とくに Git worktree との統合は、他のコーディングエージェント向け Web UI にはあまり見られない特徴です。詳細は「Git worktreeサポートの仕組み」で扱います。

設定・管理機能（モデル・APIキー・スキル）

pi 本体を CLI で運用していると、モデルの切り替え・API キー設定・スキル（pi のカスタム拡張）の管理は設定ファイルやコマンド経由になりがちです。pi-web はこれらを UI に取り込みます。

• セッション状態の可視化: コンテキスト使用量・コスト・コンパクション状態・システムプロンプトをトップバーから確認できる
• モデル・API キー・スキルの Web UI 管理: モデル選択、ログイン、API キー、スキル管理を Web UI 側で完結させられる

「今どのモデルを使っていて、どれくらいコンテキストを消費しているのか」を常時確認したい場合、CLI 上で計測するより UI 上で表示させるほうが直感的です。

UIローカライズの現状

多言語 UI についても言及されていますが、対応状況にはやや注意が必要です。README では「Use interface in your language（好きな言語で UI を使える）」と紹介されているものの、リポジトリ内の docs/i18n.md では、UI 側で提供されている言語は 英語（English）と簡体中国語（Simplified Chinese）の 2 言語 と明記されています。

リポジトリには README.ja.md（日本語）・README.ru.md（ロシア語）などの翻訳版 README が同梱されていますが、これは README の翻訳であり、UI ローカライズとは別レイヤーです。日本語 UI が業務要件になっている場合は、記事執筆時点では未対応である点に留意してください（docs/i18n.md には翻訳への貢献手順が記載されており、将来的な追加言語への貢献は公開されています）。

pi-webの導入手順

導入手順は README の「Get started」節に集約されています。ここでは README の記述に沿ってコマンドと環境変数を整理します。動作確認は行わず、公式ドキュメントの記述内容そのままの引用に留めます。

動作要件と起動コマンド

まず動作要件として、Node.js 22.19.0 以降が必要です。起動方法は 2 通り用意されています。

以下は README（https://github.com/agegr/pi-web）に記載されているコマンドです。改変は行っていません。

即時実行（推奨）:

npx @agegr/pi-web@latest

グローバルインストール:

npm install -g @agegr/pi-web
pi-web

いずれの場合も、デフォルトでは http://127.0.0.1:30141 でローカル Web UI が立ち上がる旨が README に記載されています。

起動オプションと環境変数

コマンドラインからは以下のオプションを渡せます（README「Get started」節より）。

• --port 8080: 使用するポート番号を指定
• --hostname 0.0.0.0: バインドするホスト名を指定（LAN 内公開などに利用）
• --no-open: 起動時のブラウザ自動オープンを抑止

環境変数によっても同等の設定が行えます。README で明記されている主要な環境変数は次のとおりです。

• PORT: 使用するポート番号
• PI_WEB_HOSTNAME: バインドするホスト名
• PI_WEB_PASSWORD: Basic 認証のパスワード（設定時に Basic 認証が有効化される）
• PI_WEB_NO_OPEN: ブラウザ自動オープンの抑止
• PI_CODING_AGENT_DIR: pi coding agent 側のセッションディレクトリを明示的に指定
• HTTP_PROXY / HTTPS_PROXY / NO_PROXY: HTTP プロキシ関連の設定

これらは CI サーバや社内ネットワーク配下で運用する際に、pi-web を意図した経路と認証境界の中に閉じ込めるための設定として使えます。

Basic Auth・プロキシまわりの注意

PI_WEB_PASSWORD を設定すると Basic 認証が有効になりますが、README の記載では ユーザー名は固定で pi となっています。任意のユーザー名を割り当てる仕組みは提供されていません。

pi-web が想定しているのはあくまで「ローカルワークステーション上での利用」または「限定的な LAN 内での利用」です。組織全体に公開するエンドポイントとしての運用や、多要素認証・SSO を前提とした社内ネットワーク境界での利用を想定した認証機構は README 上では確認できません。公開範囲を広げる場合は、pi-web 単独ではなく、リバースプロキシ層で追加の認証・アクセス制御を挟む設計が現実的です。

HTTP プロキシ関連の環境変数がサポートされているため、社内プロキシ環境からの起動も想定されていますが、こちらも詳細な運用パターン（プロキシ経由での外部 LLM API 呼び出し等）は各自の環境で確認する必要があります。

Git worktreeサポートの仕組み

pi-web の特徴として際立つのが、Git worktree との統合です。挙動はリポジトリ内の docs/worktrees.md にドキュメント化されています。以下では同ドキュメントの記載を要約します。

worktreeの作成と切替

プロジェクトピッカーで Git リポジトリのルートを選択すると、サイドバーに worktree スイッチャーが現れます。ここから既存の worktree を切り替えるだけでなく、「New worktree...」項目から新しいブランチ名を入力することで、<repo>-worktrees/<branch> というパスに自動でチェックアウトが作成されます。ブランチが未作成の場合は HEAD から派生した新規ブランチとして作成されます。

worktree スイッチャーが制御するスコープは、次の 3 つです（docs/worktrees.md より）。

• 新規セッションを開始するときの作業ディレクトリ
• ファイル探索（ファイルピッカー）の対象
• エクスプローラからのファイル挿入（メッセージへの添付など）の対象

「今どのチェックアウトに対して pi と会話しているのか」を UI 側で明示することで、複数ブランチを跨いだ探索でのコンテキスト混乱を減らす設計です。

セッションとworktreeの関係

セッション（pi の会話履歴）は、プロジェクトルート単位でグルーピングされて表示されます。一方でセッション自体は「開始時に属していた作業ディレクトリ」を記憶しており、worktree A で開始したセッションを続けるときは、その worktree A の中で会話が継続されます。

これにより「同じプロジェクトの下で複数ブランチのセッションが並存する」状態を、意図に沿った形で扱えます。プロジェクト単位で会話をまとめて眺めつつ、個々のセッションはそれぞれのブランチに紐づいたまま、という設計です。

worktree削除時の挙動

docs/worktrees.md によれば、pi-web の UI から worktree を削除した場合の挙動は次のとおりです。

• チェックアウト（<repo>-worktrees/<branch> の実体ディレクトリ）は削除される
• Git ブランチ自体は残る
• pi-web 上のセッション履歴も残る
• 元のメインチェックアウトには影響しない

「作業ツリーだけ片付けたいが、ブランチとセッションログは保存しておきたい」という運用要件を素直に満たす形になっています。

類似リポジトリとの違い

pi-web を検討する読者の多くは、他エコシステム向けの Web UI（Aider Browser Mode や Claude Code 系 Web UI）を既に見ている、あるいは並行して比較しているケースが想定されます。ここでは代表的な類似リポジトリと pi-web の差分を整理します。

Aider Browser Mode / aider-webuiとの違い

Aider は AI ペアプロを ターミナル で提供する OSS コーディングエージェントの代表格で、公式に Browser Mode（experimental）が提供されています（Aider 公式ドキュメント: Browser Mode）。また、サードパーティ実装として leandix-ai/aider-webui のような NiceGUI ベースの Web UI も存在します。

pi-web と Aider Browser Mode 系の主要な差分は次のとおりです。

• 対象エージェント: Aider は Python 実装で独自の diff/edit ワークフローを持つ。pi は TypeScript 実装で「エージェントハーネス」志向
• UI 機能スコープ: Aider Browser Mode はチャットとファイル選択が中心。pi-web はセッション履歴閲覧・フォーク、Git worktree 切替、スキル管理まで踏み込む
• 前提スタック: Aider は Python エコシステム前提、pi-web は Node.js 22.19.0 以降を前提とする

普段から Python 環境で Aider を運用しているなら Aider Browser Mode がそのまま延長線上に来ますが、Node.js 環境で pi coding agent を回しているなら pi-web が自然な選択肢になります。

Claude Code系Web UIとの違い

Anthropic の Claude Code CLI をブラウザから操作するための OSS プロジェクトも複数存在します。代表例は sugyan/claude-code-webui、siteboon/claudecodeui などです。加えて Anthropic 自身も 2026 年に Claude Code Desktop に組み込みブラウザを追加し、claude.ai/code で公式 Web 版を提供しています（公式 SaaS）。

pi-web と Claude Code 系 Web UI の差分は主に次の点にあります。

• 対象エージェント: Claude Code 系は Anthropic の Claude 前提。pi は OpenAI / Anthropic / Google 等の複数プロバイダに対応するマルチプロバイダ設計
• 運用志向: siteboon/claudecodeui のように「モバイル・リモートからの Claude Code 操作」を掲げる系統が目立つのに対し、pi-web はローカルセッションファイルを直接読む設計で、ローカルワークステーションでの体験向上を主眼としている
• 配布形態: Claude Code 系には公式クローズド版（Claude Code Desktop / claude.ai/code）と OSS 版が併存する。pi-web は完全に OSS でセルフホストする位置づけ

「マルチプロバイダの OSS エージェントを、自分のマシンの中で完結する UI で扱いたい」というニーズは、Claude Code 系 Web UI では正面から満たされない領域です。この隙間に入るのが pi-web です。

比較表

主要な差分を一覧化すると次のようになります（内容は各リポジトリの公式ドキュメント記載範囲での比較です）。

すでに Aider や Claude Code の Web UI を運用中のチームでは、乗り換え候補というより「pi coding agent を採用する場合に前提となる UI」として pi-web を位置づけるのが自然です。

pi-webが向いているケース／向かないケース

意思決定を後回しにしないため、pi-web が現時点でフィットする状況としない状況を整理します。「試すべきか」を判断する際の参考にしてください。

向いているケース

以下に当てはまるなら、pi-web を候補に加える価値があります。

• pi coding agent を既に使っている、または本格的な検討に入っている
• Node.js 22.19.0 以降を用意できる（npx または npm i -g で導入可能）
• セッション履歴を後から辿り、複数ブランチ・複数プロジェクトを跨いで運用したい
• モデルや API キーの切替を CLI 設定ではなく UI 上で完結させたい
• Git worktree ベースの並行開発を、エージェント込みで整理したい
• MIT ライセンスの OSS を自マシン上でセルフホストする形が要件と合う

これらは pi-web の設計が正面から支援している用途で、既存の Aider / Claude Code 系 Web UI では手薄な領域を補完します。

判断を保留すべきケース

一方、以下に該当する場合は、pi-web の採用判断を保留したり、別の選択肢と並行検討したりするのが無難です。

• UI 言語として日本語ネイティブサポートが必須: 記事執筆時点で UI 側の対応言語は英語と簡体中国語のみ（docs/i18n.md 参照）。README の翻訳版があることと UI ローカライズは別レイヤー
• 組織で公開エンドポイントとして運用したい: README 上に確認できる認証機構は Basic 認証（ユーザー名は固定 pi）のみで、多要素認証・SSO・アカウント別権限などは pi-web 単体では想定されていない。公開範囲を広げる場合はリバースプロキシ層での追加設計が前提となる
• pi 本体をまだ触ったことがない: pi-web は pi coding agent のセッションを扱う UI コンパニオンであり、単独で動作するエージェントではない。まずは pi 本体の全体像を掴んでから pi-web を導入するほうがスムーズ

3 つ目のケースに該当する場合は、pi 本体の解説記事Pi coding agentとは｜MCPに頼らず拡張できるTUIハーネスから入るのが近道です。pi 本体の設計思想（最小構成のエージェントハーネスをスキル・プロンプトで拡張する発想）を先に理解しておくと、pi-web が提供する機能の位置づけがそのまま腑に落ちるようになります。

まとめ

pi-web は、pi coding agent 向けに設計された OSS のローカル Web UI です。ポイントを 3 行に絞ると次のようになります。

• 対象: pi coding agent のローカルセッションをブラウザから扱う UI コンパニオン（MIT ライセンス・archived/fork ともに false の現行メンテナンス）
• 機能: 過去セッションの閲覧とフォーク、ファイル並行閲覧、Git worktree 切替、モデル/API キー/スキルの UI 管理、コンテキスト使用量やコストの可視化
• 差分: Aider Browser Mode 系や Claude Code 系 Web UI と比較したときの独自性は、pi coding agent という TypeScript 製マルチプロバイダエージェントのローカルセッションを主戦場にした設計と、Git worktree 統合にある

導入検討の次のアクションとしては、まず公式リポジトリの README（agegr/pi-web）と docs/ 配下（docs/worktrees.md / docs/i18n.md）で機能範囲と挙動を一次情報として確認し、pi 本体の解説記事Pi coding agentとは｜MCPに頼らず拡張できるTUIハーネスで pi coding agent の設計思想を押さえる、という順序が扱いやすいはずです。そのうえで自分の開発フロー（ブランチ運用・使用モデル・想定ネットワーク境界）に合うかどうかを判断すると、意思決定の道筋がクリアになります。