友人の見積もりを見て、試しに自分で作ってみた話

「高くて進まないんだよね」

友人から相談を受けたのは、ある日の雑談の中だった。

漫画・WEBTOONの運営会社に勤める友人が、読者反応の分析システムを作りたいと考えていた。 Xの投稿を収集して、施策の効果を測る。それをレポートにして毎週届ける。やりたいことはシンプルだった。

でも、開発会社から取った見積もりを見て、話が止まっていた。

見積もりを見せてもらったとき、正直こう思った。 要件がふわっとしているから、ボラれているんだろうな。

開発会社は悪くない。要件が固まっていない状態で発注すると、リスクを見込んだ金額になる。不確実性の分だけ、見積もりは膨らむ。これは構造的な問題だ。

なぜ自分が引き受けたのか

「試しに自分でやってみようか」と言えたのは、一緒に働いたことがある会社だったからだ。

業務フローが頭に入っていた。何を困っているか、どう使いたいか、肌感覚でわかっていた。「これしたいの？」「これしたいの？」という会話だけで、設計の輪郭が見えた。

要件定義で詰まらない、というのは大きかった。外部の開発会社が最初にやるのは「何を作るか」を言語化する作業だ。それが既に自分の中に入っていた。

まず、否定から入った

手を動かす前に、Claudeにこう投げた。「この構想の勝ち筋を、既存ツールを踏まえて否定してみて」

返ってきた否定は3つだった。

X APIの規約は年々厳しくなっている。スクレイピング系のサービスは突然死ぬリスクがある
BrandwatchやSprout Socialなど、既にソーシャルリスニングツールは存在する
漫画会社は「良い話だが緊急ではない」カテゴリで稟議が通りにくい

全部、答えられた。

X APIは公式の従量課金で使える。規約変更は想定内で都度対応する。既存ツールは「自分で設定して自分で見るもの」だ。設定・解釈・レポート化を代行することが価値になる。手動でやると死ぬほど工数がかかる作業を自動化して慣れさせれば、ロックインできる。

否定に対して全部答えられたとき、これは行けると思った。

ストレートにはいかなかった

実際に動かし始めると、想定外のことが連続して起きた。

最初の壁はApifyだった。 X投稿を収集するツールとして最初に試したが、日本語キーワードに対応していなかった。ある漫画作品のキーワードで検索すると結果ゼロ。英語キーワードでは無関係な投稿が混入した。 30分ほど試行して、X API公式に切り替えた。コストも$40/1,000件から$5/1,000件に下がった。結果的に正解だった。

次の壁はアカウントBANだった。 Developer Console登録用に新規Xアカウントを作ろうとしたところ、複数アカウント作成とみなされて全アカウントがBANされた。申し立ては時間がかかる。今日中に動くものを作ることを優先して、友人に相談したところ「使っていない古いアカウントがあった気がする」と言われた。一緒に探して見つけ、パスワードを変更して復活させた。そのまま開発を続けた。

環境変数の罠もあった。 .envファイルのパスを相対パスで書いていたが、Bearer Tokenが読み込まれず401エラーが続いた。絶対パス指定に変えて解決した。地味だが、こういう詰まりが積み重なる。

Manusで作ったモックが開けない問題もあった。 レポートのモックアップをManusに作らせてダウンロードしたが、ブラウザで直接開けなかった。 Reactアプリのためビルドが必要だったのだが、ビルド後のファイルもローカルでは正常に動かなかった。 10分ほど格闘して、「MVPのイメージ確認が目的なのでManusのクラウド上で見られれば十分」と判断して切り上げた。

一つひとつは小さい。でも全部合わせると数時間のロスになる。

それでも、1日で設計以上に進んだ

詰まったポイントはいずれも「判断を保留する」「スコープを絞る」「ツールを切り替える」の3パターンで解決できた。

1日のセッションで固まったものを書く。

ビジネスモデルの勝ち筋・負け筋の整理
ターゲット顧客と接点の確認
検証作品の選定
システム構成（X収集・AI分析・Google Docs出力）
レポートの中身と設計思想
料金体系（実費連動型マージン制・逓減モデル）
MVPの進め方

MVPとして最小限の機能に絞って外部発注できたとしても、要件定義だけで数十万円、実装まで含めると50〜130万円・18〜32人日の規模だ。それが、1日の会話で言語化・構造化できた。

しかもその日のうちに、設計で終わらなかった。リポジトリを作り、環境を構築し、パイプラインの初稿が動いた。収集→分析→Google Docs出力の3段階が、1セッションで繋がった。

残りの工程はまだある。D1スキーマの適用、4画面のUI実装、既存パイプラインのWorkers移植—— 中でも移植が唯一の難所で、googleapis非対応の問題を乗り越える必要がある。それでも、3連休で社員に見せられる状態まで持っていける見込みだ。

自分でコードを1行も書いていない。

次回：実際にどう作ったか

設計が終わったあと、実際に動くものを作る工程に入った。 Webアプリの設計、パイプラインの実装、Claude Codeによる監査——その話は次回書く。