AIエージェント専用デスクトップOSS「PI-Desktop」の仕組み

AI コーディングエージェントの選択肢は、この 1〜2 年で一気に増えました。ターミナルに常駐する型、IDE 拡張として動く型、セルフホスト可能なプラットフォーム型が並走しており、名前を並べただけでは「どれを自分たちの標準に据えるべきか」が見えてきません。

さらに判断を難しくしているのが、公式 README の書き方です。README は「何ができるか」を丁寧に書いてくれますが、「既存の選択肢とどう違うのか」「本番的に使える成熟度なのか」「顧客コードを扱う案件で社内規程を満たせるのか」といった、採用判断に直結する論点は読者が自分で組み立てる必要があります。機能一覧をいくら読んでも、候補を絞る作業は前に進みません。

vastsa/PI-Desktop は、そうした候補群のなかで「AI エージェントに専用のデスクトップ環境を与える」という少し変わった立ち位置を取っている OSS です。リポジトリの説明文は Local-first AI coding agent desktop: Electron + Rust host core + pi Agent Harness + user-installable plugins となっており、モデルのラッパーでも IDE 拡張でもなく、エージェントのためのデスクトップ基盤であると自己定義しています。

本記事は、GitHub API で取得したリポジトリメタデータと、README・公式ドキュメントサイトの記述を突き合わせて整理したものです。インストールや実行、スクリーンショットの取得といった動作検証は一切行っておらず、公開ドキュメントに基づく机上の整理であることを先にお断りしておきます。記載した数値はすべて 2026 年 10 月 5 日時点の取得値で、今後変動します。

本記事では、PI-Desktop がどのレイヤーを担う OSS なのかを構造から整理し、Electron と Rust の役割分担、プラグインで拡張できる範囲、Agent / Plan / Goal の 3 モードとセッション運用、ローカル完結と権限レイヤーの設計、導入前に確認すべき制約、そして goose・OpenHands・opencode との差分を順に解説します。最後に、採用を検討すべきケースと見送るべきケースを対照で整理します。

PI-Desktopとは｜AIエージェント専用デスクトップOSSの位置づけ

PI-Desktop は、AI エージェントが作業するための独立したデスクトップワークスペースを提供することを目的とした OSS です。README は「A modular desktop workspace for AI agents」というキャッチコピーと、「Local-first · Model-agnostic · Plugin-powered · macOS / Windows / Linux」という 4 つの性質を掲げています。

リポジトリの基本情報

まず、採用判断の前提になる事実を整理します。以下はすべて GitHub リポジトリ（vastsa/PI-Desktop） から GitHub API 経由で取得した 2026 年 10 月 5 日時点の値です。

確認しておきたいのは、このリポジトリがアーカイブされておらず、他リポジトリのフォークでもないという点です（GitHub API の archived=false / fork=false）。本家リポジトリとして現在も更新されており、最終 push は取得日と同日です。

一方で、スター数 6,358 は後述する比較対象（goose や OpenHands）と比べると一桁小さく、オープン Issue が 198 件、Watch が 16 という規模感です。採用を検討する際は、この「開発は活発だが利用者コミュニティはまだ小さい」という状態を前提に置く必要があります。

リポジトリに設定されている topics は ai-agent / coding-agent / desktop-app / electron / local-first / mcp / pi / pi-agent / plugins / react / rust / typescript / global / i18n / pi-desktop です。デスクトップアプリ・ローカルファースト・プラグイン・MCP というキーワードの並びが、そのままこのプロダクトの設計方針を表しています。

「ターミナル型」「IDE拡張型」との線引き

PI-Desktop の README は、自身の位置づけを他カテゴリとの対比で説明しています。前置きとして「Terminal agents are great at execution. IDE agents are great at living inside an editor.」と既存カテゴリの強みを認めた上で、目的を「Give AI agents a persistent, independent, and extensible desktop workspace of their own.」と置いています。

そして自己定義として、次のように明記しています。

It is not a wrapper around one model. It is not another IDE extension. It is a desktop platform for agent workflows. （出典: https://github.com/vastsa/PI-Desktop ）

つまり PI-Desktop は、特定モデルへのフロントエンドでもエディタ内の補助機能でもなく、「エージェントのワークフローを動かすデスクトップ基盤」というレイヤーを担うと宣言しています。この線引きは選定時に重要です。ターミナル型や IDE 拡張型と機能を一対一で比較するのではなく、「エージェントが長時間住み続ける場所を別アプリとして持つべきか」という問いに答えが出るかどうかが、候補に残すかどうかの分かれ目になります。

README が掲げる 4 つの柱は、Independent Workspace（独立したワークスペース）・Plugin-Powered（プラグイン駆動）・Agent Orchestration（エージェントの編成）・Model Freedom（モデルの自由）です。以降のセクションでは、この 4 つがそれぞれどう実装方針として表れているかを見ていきます。

PI-Desktopのアーキテクチャ｜Electron + Rust host coreとpi Agent Harness

リポジトリの説明文にある 4 つの要素（Electron / Rust host core / pi Agent Harness / user-installable plugins）が、このプロダクトの構成をそのまま要約しています。ここを理解しておくと、「どこを自分で差し替えられて、どこがコア固定なのか」が見えてきます。アーキテクチャの一次情報は公式ドキュメントサイトの Specs / ADRs セクションに公開されています。

Electron と Rust host core の役割分担

言語構成を見ると、どこが Rust なのかの見当がつきます。GitHub API の languages エンドポイントで取得したバイト数の内訳は次のとおりです。

TypeScript と JavaScript が全体の 8 割強を占め、Rust が約 14% です。説明文の Rust host core という表現と合わせると、UI とアプリケーションロジックの大半を Electron（TypeScript / React）側が担い、ホストとしての中核処理を Rust が担う構成であることが読み取れます。

後述するソースビルドの手順でも、cargo build -p host-core と pnpm build:js が別のステップとして並んでおり、Rust 製の host-core クレートと JavaScript 側のバンドルが独立したビルド対象になっていることが確認できます。Electron ベースであることは、クロスプラットフォーム配布（macOS / Windows / Linux）とデスクトップ UI の作り込みを両立させる選択として整合的です。

Agent / Workspace / Platform の3レイヤー拡張モデル

README には拡張モデルの図が掲載されており、PI-Desktop の下に Agent / Workspace / Platform という 3 系統が置かれています。各系統に属する拡張点は次のように整理されています。

この 3 分割が、PI-Desktop の設計思想を最も端的に示している部分です。多くの AI エージェント OSS は Agent レイヤー（ツールとスキル）の拡張に主眼を置きますが、PI-Desktop は Workspace レイヤー（エージェントが表示される UI 自体）と Platform レイヤー（常駐サービスやプラグイン間通信といったランタイム基盤）まで拡張対象に含めています。

README はこの設計を「The Core provides the foundation. Plugins decide what your workspace becomes.」と表現しています。コアは土台のみを提供し、ワークスペースが何になるかはプラグイン側が決める、という分担です。

基盤としてのpi — エンジンとデスクトップの分担

PI-Desktop の名前にある「PI」は、pi エコシステムに由来します。README は「PI-Desktop is built on the pi ecosystem.」と明記し、Agent Runtime が pi-ai / pi-agent-core / pi-coding-agent という 3 つのパッケージを利用していると説明しています。

両者の責務分担については、次のように書かれています。

Pi provides the Agent Engine. PI-Desktop builds the persistent desktop workspace, sessions, permissions, plugins, and agent orchestration around it. （出典: https://github.com/vastsa/PI-Desktop ）

エージェントのエンジン部分は pi が担い、PI-Desktop はその周囲に永続ワークスペース・セッション・権限・プラグイン・エージェント編成を構築する、という関係です。これは選定時に誤解しやすいポイントで、pi は PI-Desktop の競合ではなく土台にあたります。この点は後の比較セクションでも改めて整理します。

なお、README が pi としてリンクしているリポジトリは、調査時点で GitHub API 上では別のリポジトリ名に解決されました。リネームまたは移管が行われたとみられるため、本記事では owner 付きの厳格表記は断定せず、プロダクト名の「pi」として記述します。

アーキテクチャの詳細、採用技術、IPC プロトコル、エージェントランタイムの仕様、状態遷移といった設計資料は、公式ドキュメントサイトの Specs（仕様書）および ADRs（アーキテクチャ決定記録）に公開されています。ADR が公開されている点は、なぜその設計になったのかを後から追跡できるという意味で、長期利用を検討する側にとって評価材料になります。

プラグインで拡張できるAIエージェント機能の範囲｜Panel・Widget・MCP・Service

PI-Desktop が他の AI エージェント OSS と最も大きく違うのは、プラグインで拡張できる範囲の広さです。拡張方法の一次情報はプラグイン開発ガイドにまとまっており、空のフォルダからテスト済みの .piplug パッケージまでを扱う構成になっています。

拡張できる11のケイパビリティ

README には、プラグインが追加できる機能が 11 項目のテーブルで列挙されています。これを「エージェント機能の拡張」「デスクトップ UI の拡張」「ランタイムの拡張」に再分類すると、拡張の射程がはっきりします。

注目したいのは下 3 つのランタイム系と、UI 系の Floating Widget / Work Panel View です。エージェントが使うツールを足せる OSS は珍しくありませんが、常駐サービスを動かし、プラグイン間でメッセージをやり取りし、フローティング UI やワークスペースのビューまで足せるという組み合わせは、「エージェントが住むデスクトップ環境そのものを作り替える」という発想に立っています。

プラグインが「製品まるごと」になりうる

README は、この拡張点を組み合わせることで一つの機能群がプラグインとして完結する例を挙げています。たとえば音声エージェントなら Floating Widget（音声オーブ）と Service（常駐処理）と Agent Tool を組み合わせる、といった構成です。GitHub ワークスペースやセッション分析のような機能も、Panel や Work Panel View と Agent Tool の組み合わせで成立します。

この方針は Contributing セクションの記述にも一貫しています。独立した機能を追加しようとする際は、まず「Would this be better as a Plugin? Keep the Core focused.」という問いを通すよう促しています。コアを肥大化させず、機能はプラグイン側に寄せるという設計規律です。

採用を検討する立場から見ると、この規律は二面性があります。自社ワークフロー専用の機能を後から足せる余地は大きい一方で、必要な機能がコアに入っていない可能性も高く、プラグイン開発のコストを自分たちで負う前提になります。

配布形式とテンプレート

プラグインの配布形式は .piplug パッケージで、マーケットプレイス経由でのインストールにも対応しています。また、開発を始める際の内蔵テンプレートとして panel-basic / agent-tool-basic / skill-pack / full-demo の 4 種が用意されています。

プラグイン開発ガイドには、パーミッション設計（リスクレベルと権限宣言）、ホットリロードを使った開発とデバッグ、検証・パッケージング・インストールの流れ、リリース前チェックリストまでが章立てされています。拡張を前提に採用を検討する場合は、機能の有無よりもこのガイドの章構成を確認したほうが、必要な作業量の見積もりに近づきます。

Agent / Plan / Goalの3モードとセッション運用

ここまでが構造の話で、ここからはエージェントをどう動かす設計になっているかという運用の話になります。

3つの作業モードの使い分け

README は 3 つの作業モードを定義しています。

実行前に計画をレビューする Plan モードと、受入基準だけを与えて経路を委ねる Goal モードが分かれている点が特徴です。そしてどのモードでも、「Privileged operations still pass through PI-Desktop's permission layer.」と明記されており、権限を要する操作は後述の権限レイヤーを必ず通ります。モードの違いは自律度の与え方であり、権限チェックを飛ばす手段ではないという整理です。

SubagentとWorker Sessionの2階層委任

エージェントの並列化は、2 つの階層に分かれています。

Subagents は、独立した作業をバックグラウンドのエージェントに委任する仕組みです。README はコード探索・実装・テスト分析・リサーチ・レビューといった作業を例に挙げています。各 Subagent は独自のコンテキストを持ち、結果を親エージェントに返します。

Session Orchestrator は、より長期の作業を Worker Session 単位で委任する仕組みです。README には Worker A（Frontend）/ B（Backend）/ C（Tests）/ D（Review）のように役割で分割する例が図示されています。Worker は「Independent context · Independent execution · Directly inspectable · Reusable · Full transcript」を備えた、完全な PI-Desktop セッションとして扱われます。

この 2 階層構成で実務上の意味が大きいのは、Worker 側が「完全なセッション」である点です。親エージェントの内部状態として隠蔽されるのではなく、独立したセッションとして直接開いて中身を確認でき、トランスクリプトも残ります。並列実行させた作業の中身を後から検査したい場合、この差は無視できません。

セッションを捨てない設計と既存エージェントからの移行

作業単位の構造は Project → Session → Agent → Work で、README は「not around disposable chat threads」と明記しています。使い捨てのチャットスレッドではなく、永続する作業単位としてセッションを扱うという方針です。

具体的に可能な操作として、README は次のような項目を挙げています。

• 複数のプロジェクトとセッションの管理
• セッションの Pin（固定）・Archive（アーカイブ）・Branch（分岐）・検索
• 実行中のプロンプトキューイング
• @ によるプロジェクトファイルの参照とスラッシュコマンド
• diff レビューとコマンド出力の確認
• 右側の Work Panel による作業状況の把握
• ストリーミングチェックポイントと、中断した作業の復旧

そして「A Session can continue across multiple app launches.」と記載されており、セッションがアプリの再起動をまたいで継続します。ターミナル型や IDE 拡張型で「作業の文脈が流れてしまう」ことに不便を感じている場合、この永続性が候補に残す理由になりえます。

移行コストの観点では、既存のローカルセッションをインポートできる対象として Claude Code / Codex / OpenCode / Pi が挙げられています。すでに別のエージェントで作業履歴が溜まっている場合、その履歴を持ち込める設計になっているという記載です。

ローカル完結と権限レイヤー｜機密コードを扱う前提での評価軸

受託開発や社内の業務コードを扱う場合、機能よりも先に確認が必要になるのがデータの取り扱いです。PI-Desktop は「Local-first」を掲げているため、この点が README で明示的にテーブル化されています。

既定でローカルに残るデータと、外に出るデータ

README が示す既定動作は次のとおりです。

加えて「No mandatory PI-Desktop account.」「No mandatory PI-Desktop relay.」と記載されており、PI-Desktop 側のアカウント登録も中継サーバーの経由も必須ではないとされています。

ここで誤解を避けるために補足しておくと、「ローカル完結」はモデル推論までローカルで済むことを意味しません。リモートのモデルを使う設定にすれば、必要なコンテキストはそのプロバイダへ直接送信されます。README のテーブルが示しているのは「PI-Desktop が独自に収集・中継しない」という点であり、プロバイダへのデータ送信自体は利用するモデル設定に依存します。顧客コードの取り扱い制約を確認する際は、PI-Desktop 側の挙動とモデルプロバイダ側の規約を別々に評価する必要があります。

権限レイヤーによる自律度のコントロール

エージェントがツールを実行する際のフローは、README で次のように図示されています。

Agent
  ↓
Tool Request
  ↓
Permission Layer
  ↓
Allow / Ask / Deny
  ↓
Execution

（出典: https://github.com/vastsa/PI-Desktop ）

ツール要求が権限レイヤーを通り、Allow / Ask / Deny のいずれかに分岐してから実行される構造です。そして「You decide how much autonomy each Session gets.」と記載されており、自律度の設定はセッション単位で行えるとされています。

この粒度は運用設計に直結します。社内の実験的なリポジトリでは自動承認を広く取り、顧客コードを扱うセッションでは都度確認に寄せる、といった使い分けをセッション単位で分けられる前提になります。ただし具体的にどの操作がどのリスクレベルに割り当てられるかは、プラグイン開発ガイドの「Permission design」章や Specs の権限関連の仕様を読む必要があります。

モデルを差し替えられる設計

モデル非依存（Model-agnostic）も README が掲げる柱の一つです。対応するプロバイダとして OpenAI / Anthropic / OpenAI 互換 API / カスタムゲートウェイ / Ollama / LM Studio / ローカルモデルが挙げられています。

モデル単位で設定できる項目は、Provider / Model ID / Context Window / Output Limit / Reasoning / Thinking / Temperature / OAuth / API Key / Endpoint です。コンテキストウィンドウや出力上限まで個別に指定できる設計になっています。

さらに、セッションごとに異なるモデルを使えるほか、同一セッション内でも随時切り替えられると記載されています。README は用途別の割り当て例として、計画にモデル A、コーディングにモデル B、レビューにモデル C、機密性の高いタスクにはローカルモデル、という構成を挙げています。そして「The model is a replaceable component of the workflow — not the workflow itself.」と、モデルをワークフローの交換可能な部品として扱う方針を明示しています。

外に出せないコードを含む案件がある場合、タスク単位でローカルモデルに切り替えられるかどうかは実務上の分かれ目になります。この設計方針は、その要件を満たしうる構成として検討対象になります。

導入前に確認すべき制約｜Early Preview・LGPL-3.0・動作要件

ここまでは設計の話でしたが、採用判断で見落とされやすいのは成熟度とライセンス、そして動作要件です。裏を返せば、この 3 点を確認せずに標準ツールとして決めてしまうと後戻りのコストが大きくなります。

Early Previewという前提とリリースの動き

README には次の一文が明記されています。

Current release line: 0.16.x (Early Preview). （出典: https://github.com/vastsa/PI-Desktop ）

つまり現行のリリースラインは Early Preview 段階であると、プロジェクト側が宣言しています。これは採用判断の大前提になります。

リリースの動きをリリースページで確認すると、次のようになっています。

v0.15.10 から v0.16.1 までが 2026 年 9 月 28 日〜10 月 4 日の約 1 週間に集中しています。開発が活発であることの裏返しとして、マイナーバージョンの移動が速く、仕様の変動幅が大きい段階にあると読むのが妥当です。オープン Issue 198 件という数字も、機能追加と修正が並行して進んでいる状態を示しています。

この状況は、評価・検証目的での導入には追い風ですが、「一度決めたら半年は動かさない」前提の本番標準ツール選定とは相性が良くありません。

対応プラットフォームと動作要件

配布パッケージは README に次のようにまとめられています。

macOS 向けリリースは Developer ID 証明書で署名され、Apple の notarization も済んでいると記載されています。社内配布時のセキュリティ要件を考える際、この点は確認項目から外せます。

一方で Linux は glibc 2.35 以上 が必要とされており、README では Ubuntu 22.04 以降 / Debian 12 以降 / Fedora 36 以降が例示されています。古いディストリビューションが主戦場の環境では、この要件が導入の障壁になります。

ソースからビルドして動かす場合の開発要件は Node.js >=22.19、pnpm >=10、Stable Rust Toolchain です。README の「Run from source」に記載された手順は次のとおりです。

git clone https://github.com/vastsa/PI-Desktop.git
cd PI-Desktop

pnpm install

cargo build -p host-core
pnpm build:js

pnpm dev

（出典: https://github.com/vastsa/PI-Desktop ）

検証用のコマンドも併記されています。

pnpm typecheck
pnpm lint
pnpm test

（出典: https://github.com/vastsa/PI-Desktop ）

cargo build -p host-core と pnpm build:js が別ステップになっていることから、Rust 側のホストコアと JavaScript 側のバンドルを両方ビルドする必要があることが分かります。Rust ツールチェーンのセットアップが前提に入るため、フロントエンド中心のチームが貢献・改造を考える場合は、この点を事前に織り込んでおく必要があります。

LGPL-3.0を採用している点の確認観点

ライセンスは LGPL-3.0（GNU Lesser General Public License v3.0）です。これは README の License セクションと GitHub API の取得値で一致しています。

この領域の類似 OSS は MIT や Apache-2.0 が多く、後述する比較対象の goose は Apache-2.0、OpenHands と opencode は MIT です。LGPL-3.0 はこれらとは条件が異なるライセンスであり、自社製品への組み込みや改変物の配布を検討する場合は、条文の確認が必要になります。

本記事はライセンスの適法性や義務範囲の解釈には踏み込みません。これは法務判断の領域であるため、「このプロダクトは LGPL-3.0 であり、MIT / Apache-2.0 を前提にした社内ポリシーとは別に確認が必要である」という事実の提示までに留めます。ツール単体としてインストールして使うだけの用途と、製品に組み込む用途では確認の必要性が大きく変わる点に注意してください。

なお、README の Model Acknowledgements セクションには、開発・リファクタリング・レビュー・設計・デバッグを通じて 270 億トークン以上を使用したという記載があります（README の記載による自己申告値です）。開発の進め方そのものを AI エージェントに大きく依存しているプロジェクトであることが読み取れますが、コード品質の評価材料としては扱えません。

類似OSSとの違い｜goose・OpenHands・opencodeとの比較

採用判断で最も知りたいのは「既存の候補と何が違うのか」です。ここでは GitHub API で取得した 2026 年 10 月 5 日時点の値と、各プロダクトの README・公式ドキュメントで確認できた記述だけを使って整理します。

提供形態とサブエージェント機構の比較

比較軸は、各リポジトリの GitHub API 取得値と、各プロダクトの README・公式ドキュメントで確認できた記述に限定しています。「成熟度」のような主観評価は裏取りできる基準がないため列に含めていません。

表の出典は次のとおりです。スター数・ライセンス・主言語は goose（aaif-goose/goose）・OpenHands（OpenHands/OpenHands）・opencode（anomalyco/opencode）・Cline（cline/cline） の各リポジトリから GitHub API で取得しました。いずれも調査時点でリネームまたは移管が行われており、一般に流通している旧 owner 名の URL からもリダイレクトで解決されます。サブエージェント・委任機構の記述は goose のサブエージェント解説・OpenHands の Task Tool Set・opencode の Agents ドキュメント・Cline の Subagents ドキュメント を出典としています。

スター数の差は明確で、PI-Desktop は比較対象のなかで最も小さい規模です。導入事例や日本語の解説記事も、調査時点では見つけられませんでした。情報が少ない状態で自力で評価する必要があるという前提は、コミュニティ規模から素直に読み取れます。

一方で、提供形態の行を見ると、同じ「AI コーディングエージェント」という括りでも置かれる場所が違うことが分かります。opencode はターミナル、Cline は IDE 拡張・SDK・CLI、OpenHands は README が「self-hosted developer control center」と表現するセルフホスト型の基盤で、goose はデスクトップアプリと CLI と API を併せて提供しています。PI-Desktop はデスクトップアプリとして常駐し、作業単位を永続化する方向に寄っています。

PI-Desktopだけが持つ4つの差分

比較表と各公式ドキュメントを踏まえると、PI-Desktop 固有と言える差分は次の 4 点に整理できます。前提として、「サブエージェントによる委任」自体は比較対象 4 製品すべてが公式ドキュメントで提供を明記しており、委任できること自体は差分になりません。

1. 拡張対象に「エージェントが住むデスクトップ UI」とランタイムが含まれる — README は Panel / Floating Widget / Work Panel View / Theme（UI 系）と MCP Server / Service / Message Bus（ランタイム系）を含む 11 のケイパビリティを、プラグインの拡張点として列挙しています。比較対象各製品の拡張点の範囲は本記事では網羅的に確認していないため優劣は断定しませんが、「エージェントが表示される UI 自体」を拡張点として列挙している点は PI-Desktop の README に固有の記述です
2. セッションを使い捨てチャットとして扱わない — Pin / Archive / Branch に加え、アプリ再起動をまたいでセッションが継続します。README が「not around disposable chat threads」と明記しているとおり、作業単位の永続性が設計の前提です
3. 並列化が 2 階層に分かれ、Worker 側が検査可能 — Subagent（独立コンテキストの短期委任）と Worker Session（完全な PI-Desktop セッションとしての長期委任）が分かれており、Worker はトランスクリプト付きで直接開いて確認できます。委任の「形」は製品ごとに異なり、公式ドキュメント上では goose と Cline が並列実行を明記する一方、OpenHands の SDK は同期逐次実行を前提としています
4. ライセンスが LGPL-3.0 — 比較対象の Apache-2.0 / MIT とは条件が異なります。ツールとして使うだけなら論点になりにくい一方、製品組み込みを検討する場合は先述のとおり条文確認が必要になります

逆に言えば、これらの差分に価値を感じない場合、スター数・コミュニティ規模で勝る既存候補を選ぶほうが合理的です。差分が刺さるかどうかが、そのまま選定の答えになります。

piは競合ではなく土台

比較を考える際に混同しやすいのが pi との関係です。pi のリポジトリ（earendil-works/pi）は AI エージェントのツールキット（統合 LLM API・エージェントループ・TUI・コーディングエージェント CLI）で、調査時点のスター数は 112,466、ライセンスは MIT です。こちらもリネームまたは移管が行われており、README がリンクしている旧リポジトリ名の URL からリダイレクトで解決されます。

ただし先述のとおり、PI-Desktop の Agent Runtime は pi-ai / pi-agent-core / pi-coding-agent を利用しており、README は「Pi provides the Agent Engine.」と明記しています。つまり pi は PI-Desktop の競合ではなく依存先です。

この関係は選定時に二通りの意味を持ちます。一つは、エージェントエンジン部分は既に大きなコミュニティを持つプロジェクトに依存しているという安心材料です。もう一つは、pi 側の仕様変更が PI-Desktop に影響しうるという依存リスクです。どちらに重みを置くかは、評価する側の時間軸によって変わります。

PI-Desktopの採用を検討すべきケースと見送るべきケース

ここまでの事実を、採用判断の形に組み替えます。新しい情報は加えず、前述の内容を判断軸として並べ直したものです。

採用を検討する価値があるケース

• 複数エージェントの並列運用を前提にしたい — Subagent と Worker Session の 2 階層委任があり、Worker 側は完全なセッションとして中身を検査できます。並列実行させた作業の経過を後から追う必要がある場合、この構造は要件に合います
• ローカル完結を社内規程で要求される — Projects / Sessions / Settings / Logs がローカル保存、認証情報は OS キーチェーン、PI-Desktop 側のテレメトリなし、アカウント・中継サーバーの経由も必須ではないという既定が README に明記されています。ただしモデルプロバイダへの送信は別評価が必要です
• 自社ワークフロー専用の UI やサービスを足したい — Panel / Floating Widget / Work Panel View / Theme に加えて Service と Message Bus まで拡張できます。社内固有の運用を UI ごと作り込む前提なら、拡張の射程が広いことは直接の利点になります
• ターミナルや IDE 拡張では作業単位が流れてしまう — セッションがアプリ再起動をまたいで継続し、Pin / Archive / Branch で整理できます。長期タスクの文脈を保持したい場合に効きます
• タスクごとにモデルを切り替えたい — セッション別だけでなくセッション内でも切り替えられ、ローカルモデルにも対応します。機密性の高い作業だけローカルモデルに寄せる運用が設計方針として想定されています
• 既存のエージェント履歴を持ち込みたい — Claude Code / Codex / OpenCode / Pi のローカルセッションをインポートできると記載されています

見送り・様子見が妥当なケース

• 仕様の安定を最優先する本番標準ツール選定 — README が 0.16.x (Early Preview) と明記しており、1 週間で 4 リリースが出ている状況です。仕様変動を受け入れられない用途には向きません
• LGPL-3.0 の条件が製品組み込み方針と合わない — 比較対象の MIT / Apache-2.0 とは条件が異なります。製品に組み込む構想がある場合、先に条文と社内ポリシーの突合が必要です
• glibc 2.35 未満の Linux 環境が主戦場 — README が示す動作要件を満たしません
• 単一セッションで足りる規模の作業しかない — 並列委任と永続ワークスペースが PI-Desktop の中心的な価値である以上、その必要がなければターミナル型や IDE 拡張型のほうが導入コストが低くなります
• 日本語の情報や導入事例を手がかりにしたい — 調査時点で日本語の解説・比較記事は見つけられませんでした。英語の README と公式ドキュメントを一次情報として読む前提になります
• コミュニティ規模を重視する — スター 6,358 / Watch 16 は、比較対象（54,947〜211,772）に対して小さい規模です

次に確認すべき公式ドキュメント

候補として残す判断をした場合、次に読む順序としては以下が効率的です。いずれも動作検証を伴わず、机上で評価できる範囲です。

1. README — 本記事で引用した自己定義・capability テーブル・local-first テーブル・動作要件の原文を確認する
2. 公式ドキュメントサイトの Specs — アーキテクチャ、IPC プロトコル、エージェントランタイム、データ保存、権限 UX、セキュリティ、リリース手順までが章立てされています。ADRs を併読すると設計判断の背景を追えます
3. プラグイン開発ガイド — 拡張前提で採用するなら、Permission design の章と「Check, pack, and install」の章で実際の作業量を見積もります

まとめ

PI-Desktop は、AI エージェントに専用のデスクトップ環境を与えることを目的とした OSS です。2026 年 10 月 5 日時点でスター 6,358、フォーク 585、主言語 TypeScript、ライセンスは LGPL-3.0、最終 push は同日で、アーカイブもフォークもされていません。Electron による UI と Rust の host core を組み合わせ、エージェントエンジン部分は pi エコシステムに依存する構成です。

同カテゴリの OSS との最大の差分は、拡張の射程です。エージェントのツールやスキルに加えて、デスクトップ UI（Panel / Floating Widget / Work Panel View / Theme）とランタイム（MCP / Service / Message Bus）まで拡張対象に含めています。加えて、セッションを使い捨てにせず永続的な作業単位として扱い、Subagent と Worker Session の 2 階層でエージェントを並列化する設計を取っています。

一方で、README 自身が 0.16.x (Early Preview) と宣言しており、1 週間に 4 つのリリースが出ている段階です。スター数も比較対象より一桁小さく、日本語の情報はほぼありません。ライセンスが LGPL-3.0 である点も、MIT / Apache-2.0 を前提にしたポリシーとは別の確認が必要です。評価・検証目的での導入と、本番標準ツールとしての採用は、別の判断として扱うのが妥当です。

本記事は README・公式ドキュメント・GitHub API 取得値に基づく机上の整理であり、実行環境での動作検証は行っていません。記載したメタデータはすべて 2026 年 10 月 5 日時点の値で、スター数・バージョン・機能は今後変動します。採用を判断する段階では、本記事末尾の参考リンクに挙げた一次情報で最新の状態を確認することをおすすめします。

関連情報

AI コーディングエージェントの導入設計や、開発体制・運用フローの見直しをご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からご相談いただけます。

参考リンク

• PI-Desktop GitHub リポジトリ（README） — 本記事で引用した自己定義・capability テーブル・local-first テーブル・動作要件・ソースビルド手順の出典
• PI-Desktop 公式ドキュメントサイト — Guide / Specs / ADRs / プラグイン開発ガイドへの入口
• Specs（仕様書インデックス） — アーキテクチャ・ランタイム・権限 UX・セキュリティ・リリース手順などの設計仕様
• プラグイン開発ガイド — プラグインの作成からパーミッション設計、.piplug のパッケージングまで
• リリースページ — バージョンと配布パッケージの確認先
• 比較対象リポジトリ: goose（aaif-goose/goose） / OpenHands（OpenHands/OpenHands） / opencode（anomalyco/opencode） / Cline（cline/cline） / pi（earendil-works/pi） — 比較表のスター数・ライセンス・主言語の取得元。いずれもリネームまたは移管済みで、旧 owner 名の URL からもリダイレクトで解決されます
• 比較対象のサブエージェント機構: goose のサブエージェント解説 / OpenHands の Task Tool Set / opencode の Agents ドキュメント / Cline の Subagents ドキュメント — 比較表の委任機構の記述の出典