JavaScript9年、プロダクト出荷ゼロ。Chrome拡張初リリースで詰まったのはCSP・価格・価値提案だった

自動化の仕組みを作り上げても、「それを売り物にする」のは全く別の話だ、と気づいたのは少し後のことだった。自分は副業で AI システムを動かしているが、内部で動く仕組みを誰かに使ってもらえる形にまで持っていくには、コードの難しさとは種類が違う壁がある。

ある開発者の体験談を読んで、その感覚が言語化された気がした。JavaScript を9年書いてきて、自分名義のプロダクトを一度も出荷したことがなかった人が、ついに初めての Chrome 拡張機能をリリースした。Claude（Anthropic 社が開発した AI アシスタント）との会話から決定事項やアクションアイテムを自動で抽出するツール「Recall」だ。出荷後 48 時間で学んだことをまとめた投稿が、妙にリアルだった。

技術力は十分にある。でも「個人として何かを出荷した」経験がなければ、詰まる場所が構造的に違う。

Chrome拡張の最大の壁は、自分のコードではなくプラットフォームのCSPだった
価格を決めることが、アルゴリズムの実装より難しかった理由
「600メッセージ→10秒」が示す、価値提案の核心
「内部ツール」と「製品」の間にある、見えないギャップ
出荷してはじめて分かることが、次の設計を正確にする
まとめ
参考
【PR】フリーランスエンジニアにおすすめのツール
【PR】おすすめの書籍
1. あわせて読みたい

Chrome拡張の最大の壁は、自分のコードではなくプラットフォームのCSPだった

投稿の冒頭に書かれていたのが、CSP（Content Security Policy）との戦いだった。Claude のウェブページ上で Chrome 拡張機能を動かそうとした際に、基本機能の実装を6つの異なるアプローチで連続して遮断されたという。深夜に DOM セレクター（ページ内の特定要素を特定するための記述方法）のデバッグを続け、2度ほど諦めかけたとも書いていた。

CSP とは、ウェブサービス側が設定するセキュリティポリシーの一種だ。外部スクリプトの読み込みや、ページ構造（DOM）への特定の操作を制限する仕組みで、XSS（クロスサイトスクリプティング：悪意のあるスクリプトを他のサイトに注入する攻撃）などのリスクからサービスを守るために使われる。Claude 側がこれを適切に設定しているからこそ安全なサービスになっているわけだが、その上に拡張機能を乗せようとする開発者にとっては「自分のコードが動かない理由」として何度も立ちふさがってくる存在だ。

企業内でサーバーサイドのシステムを書いている間は、まずこういう壁には当たらない。自社のサーバーに対してコードを書き、セキュリティポリシーの設計は自分たちで決める立場にある。しかし他社のプラットフォームの上にプロダクトを乗せる瞬間から、ルールは相手が決める。「この制約の中でやれること」を把握するための固有の知識が必要になる。これは技術力の高さとは別の次元の話だ。

Chrome 拡張は特にその傾向が強い。ブラウザ上で動作するために、拡張機能が使える権限を「manifest.json」と呼ばれる設定ファイルに列挙し、その範囲内でしか動けない設計になっている。さらにアクセス先のページ側が CSP でできることを絞っているため、「拡張機能が持つ権限」と「ページが許可している操作」の重なる部分でしか動けない。ここが、一般的な Web 開発とは異なるハマりポイントだ。

自分も AI 運用の補助ツールとして Chrome 拡張を作ったことがある。ページ上のコンテンツを読み取る仕組みだったが、ページ構造の変化への対応とセキュリティ制約の把握に、想定の倍くらいの時間を使った。「コードが書けること」と「他社プラットフォームの上で安定して動くものを作れること」の間には、体感でかなりのギャップがある。

価格を決めることが、アルゴリズムの実装より難しかった理由

技術的な壁を越えた後の投稿で、もう一つ印象に残ったのが価格設定の話だった。コアのアルゴリズム実装より多くの時間を、料金プランを決めることに費やしたという。まだ正解かどうか分からないとも付け加えていた。

これはよく分かる。企業案件であれば、価格の決め方に一定のロジックがある。工数から単価を逆算して見積もりを出す。「このタスクは何時間、時給がいくらだからこの金額」という構造で決まり、あとは折衝だ。しかし個人プロダクトの価格設定には、そのロジックが使えない。

個人プロダクトの価格は「コストベース（かかった費用から算出）」ではなく「バリューベース（ユーザーへの価値から逆算）」で決める必要がある。このプロダクトはユーザーにとって何の価値があるか、それに対していくら払う気になるか、類似ツールと比較したときの適正水準はどこか——これらを全部自分で判断しなければならない。そして「この価格が正しかった」という答え合わせが、なかなかすぐには来ない。

さらに難しいのが、「自分の作ったものに値段をつける」という心理的な側面だ。エンジニアは技術的な完成度を上げることには慣れているが、それを金額に換算して他者に提示する場面には慣れていない。「本当にこの金額で払ってもらえるのか」「まだ機能が足りないんじゃないか」という不安が、判断を先送りにさせる。

副業で何かを売り始めた経験がある人ならこの感覚は共有できると思う。仕組みが動いても、「これいくらです」と言えるまでに一番時間がかかった、という経験は多い。価格を決めて出すまではゼロが続く。ここで止まっている人は技術が足りないのではなく、「値段をつける」という別の筋肉を使っていないだけかもしれない。

「600メッセージ→10秒」が示す、価値提案の核心

このツールで最も満足した瞬間として書かれていたのが、600件のメッセージがあるスレッドから決定事項を10秒で抽出できた初回だったという。アルゴリズムが完成した瞬間ではなく、「それが誰かの具体的な問題を解決する形で動いた」瞬間だ。

Claude はロングコンテキスト、つまり大量のテキストを一度に処理する能力が強みの AI だ。そのため、一つのチャット上で長い議論が続き、そこで出てきた決定事項や積み残しタスクを後から追えなくなる、というのは Claude をヘビーに使っているユーザーにとってリアルな課題になっている。Recall はその課題へのピンポイントの解答として設計されている。

プロダクトとしての価値提案の核は「何ができるか」より「何を解決するか」で決まる。機能の豊富さや技術的な完成度より、特定の場面での課題解決の解像度が高いかどうかが問われる。「600件のスレッドから10秒で決定事項を引き出せる」という一言で「それが欲しかった」と思わせられるかどうか。これがプロダクトの出口設計の起点になる。

AI ツールや自動化システムを作っていると、機能を増やす方向に引っ張られやすい。「この処理も自動化できる」「この機能も付けたい」と範囲を広げていくうちに、「誰の何の問題を解くのか」が薄れていく。1文で価値提案が言えない状態で機能を作り込んでも、出口のない仕組みが積み上がるだけだ。

「内部ツール」と「製品」の間にある、見えないギャップ

この話で考えさせられたのは、9年間エンジニアとして仕事をしてきても、個人プロダクトを一度も出荷したことがなかったという点だ。技術力は十分にある。ただ「自分のために作って、誰かに使ってもらって、お金を受け取る」という一連のサイクルを一度も回したことがなかった。

自分が使うために作ったものは、動かし方を自分が知っている前提で設計されている。エラーが出ても自分が対処できる。しかし他人が使うと、その前提が全部崩れる。インターフェースの分かりやすさ、エラーが出たときの丁寧な対応、インストール手順の明確さ、想定外の使い方への耐性——これらは内部ツールとして作る時にはほぼ意識しない要素だ。出荷してはじめて「これが必要だった」と気づく部分だ。

「仕組みは動いているのに、誰かに渡せない」という状態も、ここに原因があることが多い。技術的な出来より先に、渡せる形になっているかどうかが問題になる。自分が使っている前提と、他者が使う前提の差を埋める作業は、機能開発とは全く別の種類の仕事だ。