プラグインが壊れる理由を知ると、Claude Code の設計が一段深くなる

Claude Code の Plugin 開発が、ひとつの分水嶺に来ている。

ハーネスエンジニアなら知っておきたい Cowork でぶっ壊れる Claude Code Plugin の罠（StoreHero・永田氏）は、Claude Desktop に組み込まれた agentic 実行モード「Cowork」で CLI 向け plugin をそのまま動かすと何が起きるかを、probe ベースで7パターン整理した技術レポートだ。SessionStart hook の無音失敗、skill frontmatter hook の非発火、${CLAUDE_PLUGIN_ROOT} が VM 上に存在しないホスト側パスへ置換される——これらは単発のバグではなく、「ホスト OS ＋ ローカル Linux VM」という Cowork の二段構成アーキテクチャから導かれる構造的な差分だと指摘する。

これを「落とし穴レポート」として読むか、「設計インテリジェンス」として読むかで、開発者体験は大きく変わる。

問われているのは「どこで動くか」の先読み

Cowork では、plugin-level hook はホスト OS 側のシェルで実行され、Bash tool サブプロセスは Linux VM 内で動く。この実行場所の分断を知らないまま CLI 用 plugin を移植しようとすれば、サイレント失敗——エラーが出ず、ただ動かない——という最も調査コストが高い状態に直面する。

逆に言えば、この構造を事前に把握していれば、設計の起点が変わる。hook に何を任せ、VM 内の bash に何を任せるかを意識的に分けることで、CLI と Cowork の両環境で動く plugin を最初から設計できる。

現時点では、どこまでが正式仕様でどこまでが実装上の制約かは公開されていない。変化する可能性は十分ある。しかし「アーキテクチャから導かれる構造的な差分」という分析は、仕様が変わっても判断の軸として使える。実行場所の分断という構造が続く限り、同じ設計判断が求められるからだ。

知識コストを先払いできる局面

Claude Code Plugin のエコシステムはまだ初期段階にある。ドキュメントが薄く、前例も少ない。だからこそ、probe ベースで構造を調べ、パターンを整理した一次情報の価値は高い。

この種のレポートが出てくること自体、Plugin 開発の実践者層が厚みを増しつつあることを示している。CLI から Cowork へと実行環境が広がるタイミングで、設計の先読みに使える知識が公開された状況は、プラットフォームとして成熟しつつある兆候とも読める。

「壊れる理由を知っている」開発者は、同じ落とし穴を踏まない。それだけでなく、環境をまたいだ plugin 設計という一段上の議論に早く入れる。

再設計の出発点として使う

CLI で plugin を書いてきた開発者にとって、Cowork への対応は「移植」ではなく「再設計」が必要な場面として捉えるほうが現実に近い。SessionStart hook の挙動の違いや CLAUDE_PLUGIN_ROOT のパス問題は、確認コストが低い一方、知らないままだと原因調査で大きな時間を失う類の問題だ。

元記事が公開している probe と再現コードは、この再設計の出発点として使える。アーキテクチャの構造を手元で確認してから設計に入ることが、今の Claude Code Plugin 開発では最も堅実な前進の形と言えるだろう。

関連記事

参考文献

コメント

タイトルとURLをコピーしました