lpm: project の services、terminals、AI coding agents を 1 つのローカル workspace に寄せる

最近のローカル開発は、もう「editor を開いて terminal を 1 枚出す」だけでは済まないことが増えています。

• front-end、back-end、worker、database helper を同時に動かす;
• その横で Codex や Claude Code のような AI coding agent を走らせる;
• 別機能を並行で進めるために project copy を作りたい;
• それでも前の project の長時間タスクは止めたくない。

問題は、多くのローカル開発ツールがその一部しか面倒を見ないことです。

• terminal は command 実行だけ;
• GUI launcher は project を開くだけ;
• tmux 系は terminal に慣れた人向け;
• container 系はローカル native 開発の感覚とは少し違うことがある;
• AI agent はたいてい既存 terminal の中に押し込まれるだけ。

今日メモしておきたい gug007/lpm は、その分散を 1 か所に寄せようとしている project です。

GitHub の repository page、README、releases page を 2026-06-26 時点で確認すると、この repository は 225 stars、17 forks、作成日は 2026-03-29、repository page 上の直近公開更新は 2026-06-26 です。主な実装は TypeScript と Rust。最新 release は v0.4.52 で、公開日は 2026-06-25 です。

Project overview

項目	内容
Repository	gug007/lpm
位置づけ	ローカル開発 project 向け desktop workspace
Stars	225
Forks	17
主要技術	TypeScript、Rust
作成日	2026-03-29
直近の公開更新	2026-06-26
Latest release	v0.4.52
Release date	2026-06-25
現行 platform	macOS（Apple Silicon / Intel）

核心は「terminal を増やすこと」ではなく、「project の実行状態を集約すること」

README の冒頭には、project の start、stop、duplicate をワンクリックで行い、AI coding agent と services を同じ workspace に置くと書かれています。

ここが重要です。

本当の摩擦は、command そのものよりも実行状態の分散にあるからです。

• どの terminal が web service を動かしているのか;
• どの pane が worker を持っているのか;
• どの agent がこの codebase を読んでいるのか;
• どの directory が feature branch 用の copy なのか;
• どの project なら今安全に切り替えられるのか;

lpm は、そのばらけた実行状態を desktop 側に寄せて、1 つの local control surface にしようとしています。

特に面白いのは、project duplication を一等機能として扱っていること

README の中で一番目を引いたのは duplicate your project instantly でした。

これは今の AI coding workflow と相性が良いです。

よくある状況として、

• 1 つの agent が API を触っている;
• 別の agent が UI を試している;
• 自分は安定 workspace で review をしたい;
• 同じ working directory を共有すると簡単に衝突する;

というものがあります。

lpm は、この並行開発を例外ではなく前提として扱っているように見えます。単に window を増やすのではなく、project copy をすばやく作って複数 agent を並列で動かす ことを product feature にしている点が大きいです。

従来の launcher は「project を開く」ところで仕事が終わりますが、lpm は「並列で安全に作業できる現場を作る」ところまで踏み込んでいます。

Container orchestration より、ローカル native 開発の日常を優先している

README には No Docker required ともあります。

これは container を否定しているというより、別の現実を見ているということだと思います。

• project は最初からローカルで native に動いている;
• どの service をどう起動するかは分かっている;
• 必要なのは統一入口であって、基盤の再抽象化ではない;
• project をまたいだ切り替えを素早くしたい;

この境界の引き方はかなり明確です。

lpm は Docker Desktop や本格的な local orchestrator と同じ問題を解こうとしているわけではありません。むしろ、

「native に動かしている project と AI agents を、どうすれば散らからずに扱えるか」

という問いに集中しています。

Auto-detect があるので、単なる command 保存 launcher では終わらない

README では、次のような setup を auto-detect すると書かれています。

• Rails;
• Next.js;
• Go;
• Django;
• Flask;
• Docker Compose。

つまり lpm は、単に shell command を記録して次回再実行するだけの tool ではありません。

project の形をある程度理解し、その上で管理可能な config に落とす desktop workspace に近いです。

さらに README では、

• profiles: service の一部だけ起動する;
• actions: test、migration、deploy などの one-shot command を登録する;
• live terminal: service output をその場で見る;
• notes と config editor: project の補足情報も同じ場所に置く;

といった構成が見えます。

この組み合わせによって、lpm は「launcher 集」よりも project operations panel に近い存在になっています。

AI coding agent を明確に主役シナリオへ入れている

README では Claude Code と Codex が何度も明示されています。

これはかなり大きいです。

多くの tool は「AI agent もたぶん動く」と言うだけで、実際には terminal の上で偶然共存しているだけです。

lpm はもう少し踏み込んでいて、

• terminal layout 自体が service と agent の並走を意識している;
• project duplication が multi-agent 並列作業に自然に合う;
• project switch の設計が context と long-running task の維持を重視している;
• さらに AI Agent Skill があり、agent 自身に lpm config を作らせられる;

という形になっています。

README にある導入例は次の通りです。

npx skills add gug007/lpm

その後、agent に project を解析させ、services を見つけ、config を書かせるという流れです。

つまり lpm は、「agent を中で走らせる」だけでなく、「agent に workspace 構成自体を手伝わせる」ところまで射程に入れています。

新しい IDE というより、local project operations console と見るのが自然

README を読む限り、lpm は IDE 置き換えでも terminal テーマ tool でもありません。

むしろ関心はかなりはっきりしています。

• この project をどう起動するか;
• どの services が今動いているか;
• 別 project にどう素早く切り替えるか;
• long-running task をどう保持するか;
• 並列用 workspace copy をどう作るか;
• AI coding agent をどう同じ現場に置くか;

この焦点は、一般的な IDE や terminal multiplexer とは少し違います。

lpm は、毎日のローカル project 操作にある機械的な切り替えコストを減らすための control console と考えるのが一番しっくりきます。

向いている人

lpm は次のような人に向いていそうです。

• 複数 project をローカルで平行に触る人;
• front-end、back-end、worker、agent script を常時動かす人;
• Codex や Claude Code を日常開発の中に組み込んでいる人;
• 複数 workspace copy で並列開発したい人;
• container より native 実行を好む人。

特に、

• 毎回同じ services を立ち上げる;
• project ごとに terminal 配置を思い出す;
• 並列タスクのために directory を複製する;
• 前日に走らせた long-running task を探す;
• AI agent を正しい project context に置き直す;

という作業を繰り返しているなら、lpm の価値はかなり分かりやすいと思います。

もちろん境界もある

一方で、lpm は

• cross-platform な統一開発基盤ではない;
• team 向け remote orchestrator でもない;
• cloud-hosted な agent control plane でもない;
• production DevOps を面倒見る platform でもない。

少なくとも現時点の README と配布案内を見る限り、主戦場は macOS のローカル desktop です。

なのでこれは、

• ローカル project 切り替え;
• ローカル services と terminals の管理;
• AI agent の並列協業;
• 複数 workspace 開発時の混乱削減;

に鋭く寄った tool と考えるのが正しいです。

この交点にいる人にはかなり刺さるはずですが、remote infrastructure や team-wide orchestration を求めるなら別カテゴリになります。

まとめ

gug007/lpm が面白いのは、単に「ワンクリックで project を起動できる」からではありません。

本当に面白いのは、今のローカル開発の現実をかなり正確に捉えていることです。

• 1 つの project には複数 service がある;
• 1 人の開発者が複数 workspace を持つ;
• AI coding agent は日常の一部になっている;
• context switch と長時間タスク維持が新しい摩擦になっている;

lpm は、その摩擦を 1 つの local workspace に収めようとしています。

万人向けではありませんが、複数 service、複数 terminal、複数 AI agent を 1 台の開発機で回し始めている人には、かなり実用的な project だと思います。