野良プラグインが怖かったので自分で作った——Herdrプラグインで初めてstarをもらうまで

この記事でわかること

• Herdr のプラグインがどれくらいの手間で作れるか（TOML のマニフェスト1枚 + スクリプト）
• 他人のプラグインを入れる前に何を気にすべきか
• 自分専用のつもりで作ったツールを公開する意味

動作環境

• Herdr 0.7.4 以上
• Python 3（標準ライブラリのみ。Windows は windows-curses が必要）
• macOS / Windows / Linux

TUIが出ていると、コマンドが打てない

Herdr を使っています。ターミナルの中で複数のAIエージェントを並べて動かせるツールで、2026年3月に公開されてから5ヶ月で31,000 star を超えました。「the runtime your coding agents live on」と名乗っている通り、エージェントを住まわせるための基盤です。

複数のワークスペースでエージェントを回していると、こういう瞬間が頻繁に来ます。

エージェントが作ったファイルを、Finderで実際に見たい。VS Codeで開きたい。

やることは単純です。open . なり code . なりを叩けばいい。ところが、これが地味に面倒でした。

フォーカスが当たっているペインでは Claude CLI が動いていて、TUIが画面を占有しているからです。 シェルがそこにない。コマンドを打つ場所がない。

なので実際には、新しいタブを開くか、あるいは一度エージェントを離れて、VS Codeで対象のパスを開いたりすることになります。パスは覚えていないことも多いので、ワークスペースの実ディレクトリを確認するところから始まります。

Finder や VS Code を開くこと自体は目的そのものなので、そこは何も問題ありません。引っかかっていたのは、開くために毎回エージェントの前から一度どかないといけないことでした。タブを増やし、パスを確認し、コマンドを打つ。一回あたりは数十秒ですが、エージェントを何本も並列で走らせている最中に、この手続きが集中を細かく削っていきます。

エージェントから離れずに済むように Herdr を使っているのに、コマンドを打つためだけに離脱することになり、これを避けたかった。

既存のプラグインはあった。でも入れられなかった

Herdr にはプラグイン機構があります。そしてエコシステムはかなり賑わっていて、公式のプラグイン一覧には700個以上が並んでいます。数百 star のファイルビューアや、100 star を超えるサイドバーなど、作り込まれたものも珍しくありません。

探せば近いものはあったかもしれません。それでも入れませんでした。

野良プラグインが怖かったからです。

プラグインを入れるというのは、他人の書いたコードに自分のマシンでの実行権限を渡すということです。そして Herdr のプラグインは、ワークスペースのパスを受け取って任意のコマンドを起動できます。悪意がなくても、雑に書かれていれば事故は起きる。

これは個人的な心配というだけでもなく、Herdr 公式もプラグイン一覧のページにこう書いています。

Listings aren't reviewed by Herdr, so install at your own discretion.
（掲載されているものは Herdr が審査したわけではないので、インストールは自己判断で）

700個以上が並ぶ場所で、一つひとつコードを読んでから入れるかというと、現実的にはやりません。

結局、選択肢は「不便を我慢する」か「自分で作る」かの二択でした。

作ってみたら、意外と簡単だった

プラグイン作成のハードルは、思っていたより遥かに低いです。

Herdr のプラグインは、herdr-plugin.toml というマニフェストと、実行されるスクリプトがあれば成立します。実際に書いたものがこれです。

id = "launcher-pane"
name = "Launcher Pane"
version = "0.4.0"
min_herdr_version = "0.7.4"
description = "Click-to-launch Finder / Explorer / VS Code (and anything else you configure) per Herdr workspace, no keybinding to remember"
platforms = ["macos", "windows", "linux"]

[[panes]]
id = "launcher"
title = "Launcher"
placement = "split"
command = ["python3", "app.py"]

[[actions]]
id = "open"
title = "Open Finder/Explorer/VS Code launcher"
contexts = ["global"]
command = ["python3", "open_action.py"]

[[panes]] でペインとして表示するものを、[[actions]] でキーバインドから呼べるアクションを宣言する。中身は python3 app.py を呼ぶだけです。言語の縛りもなく、標準ライブラリだけで書けました（Windowsだけ windows-curses が要りますが、それもマニフェストの [[build]] に書けば勝手に入ります）。

そして、プラグインの作り方そのものはAIエージェントに調べてもらいました。 ドキュメントを読んで仕様を把握する工程がまるごと省けるので、「作れそうか判断する」までが速い。エージェントを動かすためのツールを、エージェントに調べさせて作る、という構図です。

作ったもの

ペインの右端に居座る、細いランチャーです。設定したコマンドが並んでいて、その下に各ワークスペースがぶら下がっている。クリックすれば、そのワークスペースのディレクトリに対してそのコマンドが走ります。 パスを思い出す必要も、打ち込む必要もありません。

コマンドは menu.json で自由に追加できます。

[
  {"title": "💻 Open in VS Code (new window)", "command": ["code", "-n", "{cwd}"]},
  {"title": "🌐 Open in Browser", "command": ["open", "-a", "Google Chrome", "{cwd}"]}
]

{cwd} がクリックされたワークスペースのディレクトリに置き換わります。argvのリストで書くのでクォートの心配もありません。

作ってから気づいた利点が2つあります。

1. ワークスペースと関係ないコマンドも置ける

{cwd} を使わなければいいだけなので、開いているパスと無関係なコマンドもワンクリックで呼び出せます。結果として、Finder を開くためのプラグインというより「よく使うコマンドを置いておくランチャー」になりました。キーバインドを覚えなくていいので、たまにしか使わないコマンドほど価値が出ます。

2. 初回実行時に確認が入る

menu.json に書いたコマンドは、そのまま実行されます。サンドボックスではありません。なので、あるコマンドを初めてクリックしたときだけ、何が実行されようとしているかを表示して確認を求めるようにしました。二回目以降はそのコマンドだけ確認なしで走ります。新しいコマンドを足せば、それにはまた初回確認が入る。

READMEにも、こう書くことになりました。

menu.json runs whatever you put in it — treat it like your shell profile, not a sandboxed setting.
（menu.json は書いたものを何でも実行する。サンドボックス化された設定ではなく、シェルの設定ファイルのつもりで扱うこと）

自分で書いてみると、他人のプラグインを入れる怖さの正体が具体的にわかります。

初日のコミットが3本。そこから細かい改善を重ねて、公開までのコミットは19本。実作業としては3日でした。

知らない人から star が付いた

しばらく経って、GitHubのリポジトリ一覧を眺めていたときに気づきました。

star が付いている。

知らないアカウントでした。そして今日また見たら、もう1つ増えていました。

数としては 2 です。バズったわけでも何でもない。それでも、正直かなり嬉しかったです。

頓挫して放置しているリポジトリを除けば、知らない人から star をもらったのはほぼ初めてだったからです。自分が使うために作って、自分のマシンにだけ入れておくつもりだったものに、会ったこともない誰かが反応した。

同じタイミングで、もう一つプラグインを作っていました。Claude Code のペイン向けに、エージェントの実際の最後の発言を macOS の通知に出すものです。こちらは star 0 でした。

差はたぶん範囲の広さです。通知プラグインは Claude Code × macOS 限定で、似たものも既にありそうな領域。一方ランチャーは Windows も Linux も視野に入れて作ったので、単純に刺さる相手が広い。

自分のために作ったものが、他人の課題でもあった

一番の収穫は star の数ではなく、「同じことで困っている人が実在した」という事実でした。

作っている最中は、完全に自分専用のツールだと思っていました。公開したのも「せっかく作ったから置いておくか」くらいの気持ちです。

でも star が付いたということは、少なくとも2人は「これ欲しかった」と思ったということです。ニッチだと思っていた不便は、ニッチではあっても自分だけのものではなかった。

正直、star より PR や issue の方が嬉しいかもしれないとも思っています。star は「良さそう」の表明ですが、issue は「実際に使って、ここで詰まった」の証拠なので。そこはまだこれからです。

まとめ

• プラグイン機構を持つツールなら、参入コストは低い。 Herdr の場合、TOMLのマニフェスト1枚とスクリプトで成立する。しかも作り方の調査自体をAIエージェントに任せられる
• 「怖いから入れない」は、作る動機になる。 公式が「審査していないので自己判断で」と明記している以上、他人のプラグインに実行権限を渡すかは自分の責任になる。それが不安なら自分で書くのが早い
• 自分専用のつもりで作ったものでも、公開する価値はある。 自分の不便は、たいてい自分だけの不便ではない

Herdr のプラグインは700個以上あり、数百 star のものも複数ある、それなりの激戦区です。それでも自分が実際に困っていることを解くものなら、置いておく意味はある——というのが star 2個から学んだことでした。

作ったものはこれです。もし同じところで詰まっている人がいれば。