小さなツールやアプリをいくつも作っていると、ある問題にぶつかります。
「これ、どうやって起動するんだっけ?」というやつです。
npm installを打って、npm run buildして、npm run devして、ローカルホストを開く。
しかも、どのリポジトリにどのコマンドが必要かも、いちいち思い出さないといけません。
数が増えるほど、この摩擦はじわじわ効いてきます。
先日、海外の掲示板Redditで、この悩みを正面から解決するプラグインの投稿を見かけました。
なぜこれを作ったのか
投稿者が作ったのは/app-itという名前のスキルです。
やることはシンプルで、手元の開発プロジェクトをDockに置けるアプリに変えてしまう。
アイコンをクリックすれば、そのままアプリが開く。
コマンドを思い出す必要はありません。
裏側ではちゃんと開発サーバーが動いています。
ただ、ユーザーがそこに触れることはない。
アイコンを押すとアプリが起動して、本物のウィンドウが開きます。
そして、終了するとサーバーも止まってポートが解放される。
投稿者の言葉を借りれば「自分のマシンに本物のアプリが並んでいる感覚」になるそうです。
開発者本人はMacユーザーです。
そのため、Mac版はかなり安定して動くとのこと。
Windows版も用意してはいるものの、実機で検証できていない。
だから、いまはベータ扱いになっています。
なぜこれを作ったのか
きっかけは、たくさんの試作品を抱える人なら誰でも覚えのある状況でした。
小さなアプリ、便利ツール、AIを使ったちょっとした実験。
こうしたものを次々と作っていくと、数週間後には「あれ、どれがどのコマンドだったか」がわからなくなります。
「自分で作ったものなのに起動方法を忘れる」というのは、考えてみればかなり間抜けな摩擦です。
コメント欄でも、この一点に多くの人が深く共感していました。
投稿者はClaude CodeやCodexといったエージェント型AIで日々大量に開発しています。
そのうちに、こうした小さくても効く工夫をいくつも見つけたといいます。
そして、それをスキルやプラグインの形にして共有しはじめました。
その第一弾がこれというわけです。
いちばん盛り上がったのは「メモリ」の話
投稿への反応で技術的にもっとも価値があったのは、リソース消費をめぐる議論でした。
あるコメントが、こう指摘します。
アプリごとに開発サーバーを立ち上げる方式は、メモリを大量に食う。
完成済みのアプリなら、Vercelに無料でホスティングしてPWA化したほうがいい。
そうすれば、同じ結果なのに1アプリあたり700MBではなく10MB程度で済む、と。
投稿者の返しが誠実でした。
たしかにその通りだが、自分の手元のプロジェクトは半分くらいがまだ作りかけだ。
しかも、ローカルのファイルを読んでいる段階で、デプロイするものがまだ存在しない。
ここがこのツールの主戦場なのだといいます。
一方で、完成したものについてはホスティングとPWAのほうが軽い、とも認めています。
そして「ビルド済みのものは開発サーバーを通さずに動かす経路を足すべきだ」と気づきました。
さらに、提案者をREADMEでクレジットすると約束しています。
別のユーザーからは、こうした方式はそもそも標準的だという声が上がります。
しかも、URLでクライアントに試作品を共有できる利点もある、と。
さらに「ただし社内環境ではVercelが承認されていない場合もある」という現実的な注意も添えられました。
面白いのはここからです。
投稿者はこのフィードバックを受けて、すぐに/app-it-staticという別スキルを作ってしまいました。
これは完成済みのアプリ向けです。
毎回サーバーを立てるのではなく、一度だけビルドして、その成果物(distやbuild、outなど)をそのまま配信する。
結果として、1アプリあたり300〜700MBだったものが、15MB程度で動きます。
しかもローカル完結なのでVercelは不要です。
だから、外部サービスが使えない閉じた社内環境でも問題なく使えます。
提案してくれた複数のユーザーは、全員が名前付きでクレジットされました。
メインはあくまで開発中のプロジェクト向けの/app-itです。
そして、完成したものには軽量な/app-it-static。役割を分けたわけですね。
指摘を受けて当日中に別ツールを作って公開し、きちんと功績を渡す。
この身のこなしの速さには、コメント欄も素直に感心していました。
Claudeのアーティファクトとつなげられるか
もうひとつ、技術好きには見逃せない横道の議論がありました。
Claudeの環境でAPIを呼び出すアーティファクトを、このスキルでアプリ化できるのか、という質問です。
投稿者の説明は率直でした。
Claude Codeはアーティファクトに直接は届かない。
なぜなら、それらはあなたのマシンではなく、Anthropic側のサーバーにあるからです。
コードを取り出す方法は2つ。
ひとつは手動でダウンロードするか、公開リンクを使うやり方。
もうひとつは、Chromeの拡張機能経由でログイン済みのClaude.aiにアクセスして引っ張ってくるやり方です。
ただし後者は手間が少ない反面、ウィンドウの状態やログインに左右されて壊れやすいといいます。
ややこしいのは、window.claude.completeというAI呼び出しを使うアーティファクトです。
これはClaude.ai内部でしか動きません。
だから、ダウンロードした瞬間にその呼び出しは死にます。
投稿者はここに別の解決策を構想していました。
これらの呼び出しを、自分のClaudeサブスクリプション経由で動くように書き換えるシム(中間層)です。
これがあれば、アプリ化したあともAI機能が生き続けます。
そして、課金は自分のサブスクに乗る。
ただし、ここには線引きがあります。
自分専用にローカルで使うぶんには問題ない。
けれど、1つのサブスクリプションを共有して、コミュニティ全体のアプリを動かすのはサブスク共有にあたります。
だから、規約上は認められません。
逆にチームでの利用なら、各自が自分のサブスクを持ち込めばいい。
そうすれば、ライセンス上の摩擦は生じない、という整理でした。
「使い道があるならぜひベータテストを」と、ここでも協業の話に発展していきます。
アイコンや、似た発想のツールたち
細かいながら気の利いた話もありました。
アプリのアイコンはどう作っているのか、という質問です。
これに対し、投稿者はCodexやChatGPTを直接使うこともあれば、Midjourneyや別の画像生成を使うこともあると答えています。
スキル自体がREADMEや起動時の見た目をもとにロゴを提案してくれる。
気に入らなければ、方向性を伝えて調整させればいい。
Dockに本物らしいアイコンが並んでいく過程が、このプロジェクトのいちばん楽しい部分だと語っていたのが印象的でした。
似た発想の道具も紹介されています。
スクリプトをアプリの形に包む既存ツールを挙げる人もいれば、自分でも近いものを作っていたという人もいました。
なかでも対照的だったのが「demo-launcher」と呼ばれる別プロジェクトの考え方です。
こちらは「ゼロフットプリント」を信条にしています。
管理側はプロジェクトを把握しているのに、プロジェクト側は管理ツールの存在をまったく知らない。
スクリプトも設定ファイルもgitに何も残さず、ディレクトリを指定すればLLMが起動方法を割り出す。
しかもWebアプリに限らず、CLIツールやiOSシミュレータ、デスクトップアプリまで同じ一覧に並べられるそうです。
これは/app-itとは正反対の設計です。
/app-itはランチャーをプロジェクトの中に書き込んで、再現性を持たせる方向。
一方は、何も残さない方向。
同じ「起動の摩擦をなくす」という目的でも、設計思想がここまで分かれるのは興味深いところでした。
なお、ClaudeやCodexがなくても使えるのか、という疑問にも答えがあります。
出来上がったアプリ自体は単体で動き、起動にAIは要りません。
ただ、最初のセットアップ部分はAIアシスタントが担当します。
具体的には、プロジェクトを調べてランチャーやアイコンを作る工程です。
そして将来的には、独立したCLIにもできるだろう、とのことでした。
フィードバックの受け止め方そのものが学びになる
技術以外でも、見ていて学ぶところがありました。
スレッドには否定的なコメントもありました。
「まだ開発中のものを取り繕っただけのゴミでは」という、かなり攻撃的なものです。
これは大きく評価を下げられました。
そして、ほかの参加者が投稿者をかばう流れになりました。
投稿者自身も感情的に反論しません。
「これは個人用の試作品向けで、製品を名乗るつもりは最初からない」と落ち着いて返しています。
むしろ印象に残るのは、建設的な指摘への向き合い方のほうです。
痛いところを突かれても防御的にならず、正しい部分は認める。
そのうえで、その場で手を動かし、アイデアの出どころを明記する。
技術そのものより、このやりとりの姿勢に共感が集まっていた気がします。
まとめ
/app-itが解いている問題は、技術的には派手ではありません。
「自分で作ったものの起動方法を忘れる」という、小さくて地味な摩擦です。
でも、その地味さこそ多くの人の実感に刺さったのだと思います。
そして、この投稿が面白かったのは、ツールそのものよりもそれを囲むやりとりでした。
メモリ消費の指摘から軽量版が生まれる。
Claudeのアーティファクト連携という新しい課題が掘り起こされる。
さらに、まったく別の設計思想を持つ似たプロジェクトまで顔を出す。
ひとつの小さなアイデアが、コメントを通じてどんどん広がっていく様子が見て取れました。
繰り返しになりますが、これは私の実践記録ではありません。
Redditで見つけた投稿とコメントを整理したものです。
それでも、開発で似た摩擦を感じている人にとっては、考え方のヒントになるはずです。
指摘を素直に受け取り、すぐ形にして、相手の手柄を認める。
道具づくりの作法としても、なかなか気持ちのいい事例でした。
