欲しいChrome拡張、話しかけたら出てきた — PlugThisは「拡張機能版Lovable」になれるか
「このサイトのこのボタン、押したら自動で○○してくれる拡張が欲しいんだよな」——そう思ったことがある人は多いはずだ。でも、実際にChrome拡張を作ろうとすると、manifest.json の書き方を調べ、content script と background script の役割の違いに頭を抱え、権限の宣言でつまづき、最後にChrome Web Storeの審査用にアイコンとスクリーンショットを用意する……という工程が待っている。作りたいものは10分で説明できるのに、形にするまでが遠い。
PlugThisは、その「遠さ」をチャットで埋めにきたツールだ。作りたい拡張を自然言語で説明すると、実際に動くコードとバックエンドまで生成してくれる。掲げているキャッチは「拡張機能版のLovable」。Webアプリを丸ごと作るLovableやv0の流れを、Chrome拡張という一点に絞り込んだ格好になる。
何をしてくれるのか
やることはシンプルだ。プレーンな言葉で「こういう拡張が欲しい」と伝えると、PlugThisが manifest、ポップアップ、content script、background script、そして必要な権限までまとめて生成する。ここまでは他のAIコード生成ツールでもできそうに聞こえるが、PlugThisが一歩踏み込んでいるのは、生成したコードがちゃんとビルドできるかを自分で検証し、壊れていれば自動で直してから見せてくる点だ。
Chrome拡張は、コードが一見それっぽくても manifest のバージョン指定や権限の記述がひとつズレるだけで読み込みに失敗する。生成AIに書かせて「動かないんだけど」となる典型的なパターンがここにある。ビルドが通ることを確認してから提示する設計は、この地味だが致命的なストレスを潰しにいっている。個人的には、機能の派手さよりこの「検証してから出す」姿勢のほうを評価したい。
さらに、ログインやデータ保存が必要な拡張のためにSupabaseと連携できる。単なるUIの飾りではなく、ユーザー認証とデータベースを持った拡張まで射程に入れているわけだ。変更はすべてバージョンとして保存されるので、「さっきの状態に戻したい」も効く。そして公開段階では、ストアが要求してくるアイコン・スクリーンショット・掲載文のコピーまで生成してくれる。
作るところから公開の一歩手前まで、途切れずに面倒を見る——という設計思想が一貫している。
なぜ「拡張機能専用」に絞ったのか
ここがPlugThisの一番おもしろいところだと思う。LovableやBolt、v0といったAIアプリビルダーは「なんでも作れる」方向に広がっている。その中でPlugThisはあえて逆を行き、Chrome拡張という狭い箱に自分を押し込めた。
狭く絞ると何が起きるか。生成AIにとって「何を作るか」の探索空間が一気に小さくなる。拡張機能はファイル構成も、権限モデルも、ストア申請のフローもある程度決まっている。汎用ビルダーが毎回ゼロから設計を考えるのに対し、PlugThisは「拡張機能とはこういうものだ」という前提を最初から握っている。だからビルド検証も自動修復もストア用アセット生成も、専用に作り込める。
汎用ツールが「広く浅く」なりがちな領域で、「狭く深く」を選ぶ。これは正しい賭けに見える。Chrome拡張は個人開発者やスモールビジネスが「自分のワークフローに合った小さな道具」を作りたい需要が根強くあり、しかも技術的なハードルが微妙に高い。その隙間はたしかに存在する。
これがあると何が変わるか
一番わかりやすいのは、「社内ツール」を非エンジニアが自分で作れるようになる未来だ。たとえば「うちのCRMの管理画面に、ワンクリックで定型コメントを挿入するボタンを足したい」といった要望は、どの会社にもある。でも情シスに頼むほどでもなく、外注するには小さすぎる。こういう「隙間の自動化」は、これまで誰も手をつけずに放置されてきた。チャットで拡張が作れるなら、現場の担当者が自分でその隙間を埋められる。
もうひとつ、個人開発者の「アイデア→収益化」の距離が縮む可能性がある。Chrome Web Storeは、小さな便利ツールが有料や広告で回りうるマーケットだ。これまでは「作れる人」だけが参加できた。PlugThisがストア掲載文やスクリーンショットまで面倒を見るなら、企画力はあるがコードは書けない人が参入できる。玉石混交にはなるだろうが、niche な課題を解く拡張の総数は確実に増える。
ここから一歩踏み込んだ話をすると、PlugThisが生成する拡張がMCPのようなAIエージェント連携の受け皿になれれば、意味合いはさらに変わる。ブラウザ上の操作をエージェントに渡す「手足」を、ユーザー自身がチャットで量産できる——という絵は、条件が揃えば十分あり得る。今のPlugThisがそこまで見据えているかは不明だが、「ブラウザ内の小さな自動化を誰でも作れる」という土台は、その方向と地続きだ。
気になる点
期待の裏で、正直に引っかかる点も挙げておく。
まず、生成AIによるコード生成に共通する「複雑になると崩れる」問題から、PlugThisも無縁ではないはずだ。シンプルなポップアップやボタン追加は得意でも、複数のサイトをまたいで状態を管理する複雑な拡張、DOMが激しく変わるSPA相手の安定動作あたりは、チャットの一言では詰めきれない。ビルドが通ることと、意図どおりに動き続けることは別の話だ。
次に、メンテナンスの問題。拡張は作って終わりではない。対象サイトのHTML構造が変われば動かなくなるし、Chromeの manifest 仕様も更新される。「作るのは簡単、直し続けるのは大変」という構造は、ノーコードで作った拡張ほど深刻になりやすい。生成物のコードを自分で読めない人が、壊れたときにどうするのか——ここはツール側の継続的な追従に期待するしかない。
そして料金。本稿執筆時点で明確な日本円ベースの価格情報を確定できなかったため、実際に使う前に公式サイトで最新のプランを確認してほしい。この手のAIビルダーは生成回数やプロジェクト数で段階課金するのが定石で、「無料で試して、量を作るなら課金」という構造になっているケースが多い。
どんな人に向くか
刺さるのは、「作りたい小さな拡張のアイデアが具体的にある、でもコードは書けない(書きたくない)」人だ。業務効率化のための社内向け拡張を試作したい人、Chrome Web Storeで小さなプロダクトを試したい個人開発者、そして「AIにコードを書かせる」体験を拡張機能という小さな題材で試したいエンジニアにも入り口として面白い。
逆に、複雑で長期運用が前提の拡張を本気で作るなら、生成されたコードを自分で読んで手を入れられることが前提になる。そこはPlugThisに丸投げする領域ではない。
汎用AIビルダーが「なんでも作れる」を競う中で、あえて一点に絞ったPlugThisの割り切りは、少なくとも方向性として気持ちがいい。狭い箱の中でどこまで完成度を上げられるか——そこが評価の分かれ目になりそうだ。詳細はPlugThis公式サイトを確認してほしい。
関連記事
コーディングエージェントは、なぜ黒い画面ばかりなのか — JUCE作者が出したGUIツール「Juggler」
JugglerはAIコーディングエージェントを可視化・操作するGUIワークベンチ。JUCE作者が開発。CLIとの違い、CRDTセッション設計、Claude Code等との立ち位置を解説する。
会話だけでDockに「本物のMacアプリ」が増える — Raycastが出したGlaze
RaycastのGlazeは、チャットで説明するだけでネイティブMacアプリを生成するツール。Product Hunt 1位を獲得した実力、料金、Xcodeでコンパイルする仕組みと弱点を解説する。
「自分のサーバーで動くDify」が欲しい人へ — 2.8万スターを集めたOSSエージェント基盤Sim
オープンソースのAIエージェント構築ワークスペース「Sim」を解説。ドラッグ&ドロップのビジュアルビルダー、1,000以上の連携、セルフホスト対応。Dify・n8nとの違い、料金、使いどころを整理する。