Pinvou Agent を採用する前に読む: 成果物を残すデスクトップエージェントの構造と境界
Open-source desktop AI agent for tools, files, knowledge, workflows, and real deliverables.
ひと目でわかる
- これは何？
- Rust と Tauri で書かれたデスクトップ型 AI エージェント。作業・デザイン・コーディングを 1 つの画面にまとめ、チャットではなくファイルを残す設計になっている。MIT ライセンスのプレビュー版を、導入判断の観点から分解する。
- 誰に向いている？
- 導入を検討すべきなのは、PDF や Office 文書を添付して調査・執筆し、その結果をファイルとして再利用したい個人や小規模チーム、および Codex・Claude Code・Kimi を ACP 経由で同じ作業机に集約したい開発者です。逆に、CI に組み込む自動化基盤や、複数人で共有するサーバー常駐型のエージェントを必要とする場合は適しません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
チャット欄ではなく成果物置き場として設計されている
多くのデスクトップ AI クライアントは、会話ログが最終成果物になる。Pinvou Agent の README はこの前提をはっきり否定していて、タスクは結果で終わるべきだと書いている。具体的には、エージェントが作成・編集したファイルを Artifact パネルが自動で集約し、プレビュー、所在の確認、外部アプリでのオープンまでを一箇所で行う。Markdown の成果物はアプリ内で直接編集でき、一部の段落を選択してエージェントに書き直させることもできる。対象読者は、調査レポート、提案資料、ポスター、データ可視化のように、テキスト以外の形で他人に渡すものを日常的に作る人だ。チャットの要約をコピーして別のツールに貼る手間を、ツール側が引き受けるという発想になっている。
3 つのモードと ACP という外部エージェント接続
作業面は Work、Design、Code の 3 モードに分かれる。Work は添付ファイル、ローカル知識ベース、ペルソナ、Skills、MCP ツール、ワークフローを組み合わせて調査と納品物を作る。Design は自然言語からポスターやデータ可視化を生成し、その後の編集を要素選択とプロパティ変更で行う。Code は自前のコーディング機能ではなく、Codex、Claude Code、Kimi を ACP 経由で呼び出す。ACP の詳細は docs/multi-agent-acp.md にあり、本稿では中身を確認できていないが、README によれば外部エージェントは実プロジェクトか隔離された一時ワークスペースを読み書きし、コマンドを実行し、計画、ツール実行の各ステップ、権限要求、ファイル変更を画面に出す。セッションはワークスペースに紐付き、アプリを再起動しても継続できる。つまり Pinvou 自身はコーディング能力を抱えず、既に使っているエージェントを UI 側で束ねる立場を取っている。
データは ~/.pinvou3/ に集まり、外に出るかどうかは構成次第
セッション、設定、知識ベース、実行時の拡張はすべて ~/.pinvou3/ 配下に置かれる。知識ベースはローカルに構築され、全文検索とベクトル検索の両方を使い、1 つのチャットに複数のコレクションを紐付けて個別に有効化・無効化できる。回答にはコレクションとファイルの出所が保持される。メモリセンターは長期的な嗜好や文脈を候補として提示し、ユーザーの確認を経て確定する。ここで重要なのは、ローカル完結かどうかを決めるのはアプリではなく構成だという点で、README も注記で明言している。ローカルモデルとローカルツールの組み合わせなら閉じるが、クラウドモデル、リモート MCP サーバー、サードパーティのコネクタを使えば、それぞれのサービスへ該当リクエストが送られる。Feishu、DingTalk、WeCom、Tencent Meeting、Tencent ima、Obsidian などの既成コネクタが用意されている以上、これらを有効にした時点で完全ローカルという説明は成立しない。
モデル接続は OpenAI 互換エンドポイントに寄せている
モデルはローカル vLLM と OpenAI 互換 API の両方に対応する。複数のモデル構成を保存でき、クラウド構成には表示用の別名を付けられる。別名を付けてもプロバイダに送られるモデル識別子は変わらない、という挙動が README に書かれている。セッション単位で切り替えられるため、機密性の高い作業だけローカルに落とす運用が現実的だ。組み込みテンプレートには local vLLM、DeepSeek、Kimi、Qwen、Doubao、MiniMax、Zhipu (GLM)、MiMo、OpenAI、Anthropic、Gemini、xAI が並ぶ。README が示すローカル vLLM の例は次の通り。
export DEEPSEEK_BASE_URL="http://127.0.0.1:8000/v1" export DEEPSEEK_API_KEY="local-no-auth" export DEEPSEEK_MODEL="your-model-name"
エンドポイント、モデル名、API キーはアプリの設定画面からも管理できる。環境変数名が DEEPSEEK_ で始まるのはテンプレート由来の命名で、実際には任意の OpenAI 互換サーバーを指せる。
ツールは MCP と CLI と API を 1 つの棚に並べる
ツールストアはローカル MCP サーバー、リモート MCP サーバー、CLI ツール、API コネクタを同じ場所で扱う。対応しているものは OAuth / SSO で認可でき、API キーを手で貼る作業を減らせる。Skills、Commands、ワークフローは、うまくいった手順を再利用可能な形に固定する仕組みで、毎回プロンプトを書き直す運用からの移行を想定している。加えて、スマートフォンから QR コードを読んで実行中のワークスペースを閲覧・操作するリモートコントロールがある。ここは設計上のトレードオフがはっきり出る部分だ。接続先が増えるほど便利になるが、データが外に出る経路も同時に増える。README の注記はその点を曖昧にせず、有効化したモデルとツール次第だと書いている。導入時にはツールストアの棚を上から順に有効化するのではなく、業務ごとに必要な最小構成を決めてから足すほうが安全だ。
プレビュー版であることと、更新経路の未整備
リリースは v0.9.3、v0.9.2、v0.9.1 と続き、いずれも「Pinvou 0.9.x プレビュー版」という表記で 2026 年 9 月に公開されている。0.9 系であることとプレビュー表記が重なるため、業務の基幹フローをこれに依存させるのは時期尚早と判断できる。更新は GitHub Releases 経由で、アプリ内のアップデート確認はまだ有効になっていないと README が明記している。つまり利用者は新しい版が出たことに自分で気づき、手動で取得して入れ替える必要がある。セキュリティ修正が出た場合の反映も同じ経路になる。CI は pr-check.yml が用意されているが、これは PR の検査であって配布物の自動更新ではない。運用コストを見積もるなら、この手動更新の手間を人数分だけ計上しておくべきだ。
ローカル常駐型の代替と、サーバー型エージェントとの違い
比較対象として分かりやすいのは、サーバーに常駐させて API 経由で呼ぶタイプのエージェント基盤だ。あちらは複数人で同じセッションを共有でき、CI やバッチからも起動できる。Pinvou Agent はデスクトップアプリで、データは各ユーザーの ~/.pinvou3/ に閉じる。共有も自動実行も設計の中心にない。逆に、サーバー型では自前で用意する必要があるものを、こちらは画面として持っている。Artifact パネル、Design モードの要素編集、メモリ候補の確認 UI、GPU・メモリ・ディスク・モデルサービス・コンテキスト使用量の集中監視、オンデマンドで音声モデルを取得するローカル音声入力などがそれにあたる。同じ MCP を使うにしても、サーバー型は接続設定をコードで管理し、Pinvou はツールストアの画面で管理する。どちらが優れているかではなく、設定をリポジトリに置きたいか、各人の端末に置きたいかの違いである。
ライセンスと、導入前に潰しておくべき確認事項
ライセンスは MIT で、デスクトップアプリのコードを自組織の要件に合わせて改変し、再配布することも許容される。ただし本稿は法的助言ではない。同梱されるモデルの重み、MCP サーバー、CLI ツール、API コネクタはそれぞれ別のライセンスと利用条件を持ち、MIT が及ぶ範囲は Pinvou Agent 自身のコードに限られる。次に確認すべきはビルド経路だ。README には Quick Start の節があるが、本稿で参照できた範囲には具体的なビルドコマンドが含まれておらず、Rust と Tauri と React で構成された pinvou3-app を自分でビルドできるかは判断できない。ソースから動かす前提なら、リポジトリの docs と .github/workflows/pr-check.yml を先に読み、必要なツールチェーンとプラットフォーム別の依存を洗い出す必要がある。最後に、業務で使うなら ~/.pinvou3/ のバックアップ方針を決めておきたい。セッション、設定、知識ベース、拡張がすべてこの 1 ディレクトリに集約されているため、ここを失うと作業環境ごと失う。
編集部の結論
導入を検討すべきなのは、PDF や Office 文書を添付して調査・執筆し、その結果をファイルとして再利用したい個人や小規模チーム、および Codex・Claude Code・Kimi を ACP 経由で同じ作業机に集約したい開発者です。逆に、CI に組み込む自動化基盤や、複数人で共有するサーバー常駐型のエージェントを必要とする場合は適しません。デスクトップアプリであり、データは各ユーザーの ~/.pinvou3/ に閉じるためです。導入前に確認すべきは 3 点で、第一に自組織のデータが外部に出る経路、すなわち有効化するモデル、リモート MCP サーバー、Feishu や DingTalk などのコネクタの組み合わせ。第二に v0.9.x が preview 表記であり、更新も GitHub Releases からの手動取得で、アプリ内アップデート確認が未実装である点。第三に、README にビルド手順が載っておらず Quick Start の中身も本稿では確認できないため、自分でビルドする前提ならリポジトリの docs と CI 定義を先に読む必要があります。
コミュニティノート