「毎朝1アプリ量産」ができる仕組みを組んだ。3日後、自分で止めた

「毎朝1アプリ量産」ができるパイプラインを組んだ。

Day 1: 市場から7本ネタを発掘し、1本選定して仕様書化、手動デプロイで1本リリースした。 Day 2: 翌朝6時に8本発掘、1本選定して全自動デプロイ初成功。同日夜にもう1本手動デプロイ。 Day 3: 派生機能の追加・改善が走り、合計5本のWebアプリがVPS上に並んだ。

Day 4の朝、自分でこのパイプラインを止めた。

止めた理由はバグでもエラーでもない。コストだ。具体的には、Claude API のトークン枠を毎朝使い切っていて、このまま回し続けると月のサブスク枠を超えて従量課金が走り続ける構造になっていた。自動化が黒字で回らないなら、自動化じゃない。

この記事は、「全自動でアプリを量産する」という構想を3日で実装し、3日で停止した実録だ。失敗系の話だが、止める判断ができたこと自体が業務OSの成長だと思っている。

100日で約144スキルを組んでくる中で、最も「自動化の限界線」を学んだプロジェクトだった。同じことを考えている人へ、量産パイプラインを組む前に知っておくべきコストエコノミクスの罠を共有する。

何を作ったか — App Factory の全体像

組んだのは「App Factory」というMicro SaaS量産パイプライン。コンセプトは単純だ:

毎朝6時、市場から商品アイデアを発掘し、自動で仕様書化、自動で実装、自動でデプロイする。1日1アプリを目指す。

具体的なフローは6ステップ:

[Step 1] idea-scout
  └ WebSearch + Playwright で AppStore / Gumroad / X / ProductHunt を巡回
  └ 「需要のあるネタ」を 5〜10 本 inbox に投入

[Step 2] idea-triage
  └ 100点スコアリング（外販売ポテンシャル10点を含む7軸）
  └ 上位 1 本を選定

[Step 3] spec-writer
  └ GitHub Issue を自動起票（要件・SLOTS・API設計）

[Step 4] app-builder
  └ Claude Code で実装 → ビルド → GitHub リポ作成 → deploy-app.sh 実行

[Step 5] sync_to_products.py
  └ x-autopilot（X 自動投稿）に新アプリを連携、告知ポストをキュー追加

[Step 6] git commit & push
  └ 全変更を ops リポジトリにコミット

ホスティングは VPS の nginx リバースプロキシ。個別 CNAME を Cloudflare DNS API で自動追加し、SSL は certbot で自動取得する。新アプリのドメイン取得から SSL 化まで、人間の介入は0。

VPS cron に 1 行登録するだけで、毎朝6時にこのパイプラインが起動する:

0 6 * * * /root/ops/app-factory/scripts/run-factory-morning.sh

このcron 1行で「毎朝アプリが1本生まれる仕組み」が成立する設計。コードを書く部分、調べる部分、デプロイする部分、告知する部分が全部自動化されている。

非エンジニアの自分にとって、これは「自分でアプリを書ける」を超えて「自分が寝てる間にアプリが生まれる」状態だった。

3日で5本デプロイした

Phase 2 完全自動化が稼働した4月中旬、3日で5本のアプリがVPSに並んだ。

Day	アプリ	カテゴリ	デプロイ方式
1	AI Product Description Generator	EC支援	半自動（人間が承認）
2 朝	EC AI Readiness	EC診断	全自動デプロイ初成功
2 夜	ShopPilot	Shopify診断	手動デプロイ
3	Review Reply AI	レビュー返信	半自動
3	Review to LP	レビュー→LP変換	半自動

このうち「Day 2 朝のEC AI Readiness」が全自動デプロイの初成功だった。CronがAPIを叩き、市場ネタを発掘し、仕様書を書き、実装を生成し、Cloudflare DNS を追加し、SSL 証明書を発行し、X に告知ポストを投げる — これが人間の介入なしで完走した。

朝起きて通知ツールを見たら、新しいアプリの URL が並んでいた。「動いた」というよりは「動きすぎた」感覚だった。

各アプリは独立した CNAME を持ち、ストアフロント風の小さなランディングページがついていて、即時に使える状態でデプロイされる。

https://ai-product-desc-gen.apps.taigi-i.com
https://ec-ai-readiness.apps.taigi-i.com
https://shoppilot.apps.taigi-i.com
https://review-reply-ai.apps.taigi-i.com
https://review-to-lp.apps.taigi-i.com

ここまで聞くと「最高じゃん」と思う。実際、自分も思った。**「これを365日続けたら、年間365本のSaaSが手元に揃う」**と。

問題は、その計算が机上の空論だったことだ。

何が起きたか — トークン枠が毎朝燃えていた

Day 4の朝、Anthropic のダッシュボードを開いて気づいた。月のトークン枠の消化ペースが、月末を待たずに枯れる勢いだった。

当時のサブスクは Claude MAX 5x プラン($100/月)。これは「重めのClaude Code利用者」向けの上位プランだ。普通の対話用途なら、月の枠を使い切ることはまずない。

でも、App Factoryのパイプラインは違った。

idea-scoutで Playwright を起動して4サイトを巡回するだけで、Claude のコンテキストに数万トークンの調査結果が積み上がる。idea-triage は7軸スコアリングで全候補を比較する。spec-writer は要件定義を書き、app-builder は Claude Code が完全自動でアプリを実装する。

1サイクルで使うトークンが、1日の「普通の利用者」の数倍になる。これを毎朝6時に走らせれば、月末を待たずに枠が尽きる。

枠が尽きると Anthropic は2択を迫る:

追加使用量を ON にする → 枠超過分を従量課金で叩く
追加使用量を OFF のまま → 枠が尽きた瞬間からClaudeが応答しない

自分は当時、追加使用量ONにしていた。理由は「枠が尽きたら他のスキルも止まると業務が回らないから」。これが罠だった。

ある朝、ダッシュボードに**$0.58の従量課金が記録**された。たかが$0.58だが、これは「自動化が、毎日少しずつお金を吸い始めた」というシグナル。

このまま3日放置すれば $1.74、1ヶ月放置すれば $17.40。ペースが上がれば月数十ドル、年間数百ドルの「予測しなかった支出」が発生する。

自動化のレバレッジが、コストの暴走に変わる瞬間だった。

自分で止めた — 4日目の朝

Day 4の朝、VPS cron をコメントアウトした:

#DISABLED 0 6 * * * /root/ops/app-factory/scripts/run-factory-morning.sh

止めた判断の根拠は3つ:

根拠①: 量産しても「使われる」アプリは限定的

3日で5本デプロイしたが、実際にトラフィックが来ていたのはShopPilotだけ。残り4本は「動くがほぼ使われない状態」のまま並んでいた。

App Factory稼働前から運用していた1号機のCrew(クライアントポータル)と、量産期に出てきたShopPilot(Shopify診断ツール) — 磨き込みに値する候補として残ったのは、この2本だけだった。

量産能力 = 価値創出能力ではない。100本デプロイしても、99本が誰にも使われないなら、それは「動くゴミの量産」だ。

根拠②: 追加使用量ON は終わりが見えない

$0.58 で止まった理由は、自分がたまたまダッシュボードを毎朝見ていたから。見ていなければ $5、$50、$500と上振れる構造だった。

「予算上限なし」の従量課金は、自動化と相性が最悪。自動化は「人間が見ていない間に走る」ことが価値だが、コストも「見ていない間に積み上がる」。

根拠③: 量産より、運用の自動化のほうが価値が大きい

App Factory が止まっても、個別アプリの運用cron は今も動いている。

Shopify 関連の運用 cron だけで、現時点でこれだけ稼働している:

30 7 * * * shopify-daily-sales-report.py    （毎朝7:30 売上レポート）
0 9 * * * shopify-inventory-alert.py        （毎朝9時 在庫警告）
*/10 * * * * shopify-sale-runner.py         （10分おき セール価格更新）
0 10 * * * shopify-competitor-monitor.py    （毎朝10時 競合価格監視）
*/10 * * * * shopify-sale-banner.py         （10分おき バナー切替）
0 8 * * * shopify-ga4-report.py             （毎朝8時 GA4レポート）
0 6 * * * shopify-pdca-analyze.py           （毎朝6時 PDCA分析）
*/30 6-22 * * * shopify-pdca-executor.py    （30分おき PDCA実行）

これらは全部 --model sonnet 固定。Opusは使わない。用途が明確で、トークン消費が予測可能で、効果測定ができる。

量産パイプラインは止まっても、運用パイプラインは生き残った。これが正しい姿だと思う。

教訓 — 自動化のコストエコノミクス

3日で組んで3日で止めたこのプロジェクトから、AI業務自動化の限界線について5つの教訓を引いた。

教訓①: 自動化のレバレッジは「実行能力」ではなく「コストエコノミクス」で決まる

「APIを叩ける」「コードが書ける」は前提条件であって、自動化の本質ではない。

本質は「毎日叩き続けて、黒字で回るか」だ。1回回すと$0.10かかる処理を1日100回走らせれば $10/日 = 月$300。これがビジネス上のリターンを生み続けるかで、自動化を維持するかが決まる。

App Factoryの場合、リターン(=量産アプリ売上)よりコスト(=毎朝の量産トークン)のほうが圧倒的に大きかった。だから止まった。

教訓②: 全自動化を「全部Opus」で組むと必ず破綻する

Opus 4.7 は最も賢いモデルだが、Sonnet 4.6 の5倍、Haiku 4.5 の十数倍のコストがかかる。全工程をOpusで回すと、月末にトークン枠が尽きる。

正解は3階層モデル:

Haiku 4.5 — ニュース収集・要約・形式変換などの軽量処理
Sonnet 4.6 — KPI分析・レポート・コンテンツ生成（デフォルト）
Opus 4.7 — QC・売上推定・戦略判断などの「失敗が信用毀損になる」タスクのみ

App Factoryで止まった量産パイプラインは、各ステージで複数モデル混在で動いていた。これがトークン消費を予測不能にした。一方、生き残ったShopify系cronは全部Sonnet固定。消費が予測可能だから、回し続けられる。

教訓③: 「量産」は手段、「価値検証」が目的

「毎朝1アプリ量産」というコンセプトは魅力的だが、これは目的じゃなく手段だった。目的は「当たりを見つけて磨き込む」こと。

3日で5本デプロイして気づいた。当たりを見つけるには量産が必要だが、磨き込みには時間とフォーカスが必要だ。量産しすぎると、磨き込む対象が定まらない。

止めた今、Crew(クライアントポータル)とShopPilot(Shopify診断ツール)の2本に絞って磨き込んでいる。これが正解だった。

教訓④: 自動化を組んだら、止める基準も組む

普通、自動化は「動かす設計」だけ考える。でも実は**「止める基準」も最初から組んでおくべき**だった。

App Factoryに後から追加した停止条件:

月のトークン枠が80%消化したら自動stop
追加使用量ONで$5を超えたら通知
7日間で1度も稼働せず・1度もトラフィックが来ないアプリは「ゾンビ判定」

「止める基準」を設計に組み込むことで、自動化が暴走するリスクを構造化できる。これは Hook で機械的に止めるのが理想だ。

教訓⑤: 追加使用量ON は、自動化と相性が最悪

これは Anthropic API 特有の話だが、自動化を組むなら追加使用量は常にOFFが原則。

自動化は「人間が見ていない時間に走る」ことが価値だ。コストもその時間に積み上がる。人間が見てない時間に課金され続ける構造を、自分から有効化してはいけない。

枠が尽きたら止まるほうが安全。止まったことに気づいてから、サブスクのアップグレードか、自動化のスコープ縮小か、を判断すればいい。

「止まる」を「失敗」と捉えると、追加使用量ONに飛びつく。「止まる」を「正常な制動」と捉える設計思想が必要。

クライアントの業務自動化に応用する

このプロジェクトで学んだコストエコノミクスは、ECコンサルとしてクライアントの業務自動化を提案するときにも効く。

クライアントが「AIで業務を全自動化したい」と言ってきたとき、自分の答えはこうなった:

「全自動化はやめましょう。1業務ずつ、目的特化で自動化を積み上げましょう」

理由は:

全自動化は、コスト構造が読めない(複数モデル混在・実行回数不確定)
目的特化の自動化は、コスト構造が読める(モデル固定・実行回数限定)
「動く」と「回し続けられる」は別の話(初期実装と運用維持は違うスキル)

例えばあるEC事業者の場合、「商品ページ自動生成」「在庫アラート」「KPIモニタリング」「メルマガ作成」を1つずつ目的特化cronとして組む。全部一気にやるより、1つずつ動かして、1つずつコストを実測しながら積み上げる。

自分がEC事業者向けに運営している「AI業務改革プログラム」(6ヶ月伴走型のAI研修)でも、これがクライアントと一緒に設計するときの最重要の前提条件になっている。

業務OSにおける位置づけ

100日で組み上げた業務OS全体(約144スキル × 6サブエージェント × 15Hook × 3モデル × 3方式自動実行 × 月¥36,237)の中で、App Factory の停止は**「モデル層×時間軸の整合性失敗」**だった。複数モデルが混在する量産パイプラインを毎朝VPS cronで起動した結果、コスト消費が予測不能になり、「人間が見てない時間」に課金が積み上がる構造を作ってしまった。レイヤーが疎結合でも、コストの観点では結合する。これは6レイヤー設計に追加した、新しい横断ガードだ。

止めた今、何が動いているか

Day 4 に App Factory の cron をコメントアウトしてから2週間以上経った。今、業務OSで動いているのはこういう状態だ:

領域	自動化レベル	コスト
量産パイプライン(App Factory)	停止	$0
Shopify 個別運用cron(8本以上)	稼働	Sonnet固定で月内枠内
朝のニュース配信(ai-ops/ec-ops/cc-ops)	稼働	Sonnet固定
KPIモニタリング	稼働	Sonnet固定
クライアント診断・分析(対話)	オンデマンド	Opus(qc-checker)+Sonnet
Crew / ShopPilot 運用	手動メンテ	個別

動いているのは「目的特化・コスト予測可能・効果測定可能」な仕組みだけ。量産は止まっている。

3日で5本デプロイした記憶はあるが、365本/年を狙う計画は破棄した。残ったCrew・ShopPilotの磨き込みに集中するほうが、自分の3ヶ月後・半年後の収益曲線に効くと判断した。

これから自動化を組む人へ

100日で約144スキルを動かす業務OSを組みながら、最も意外だった学びは「自動化は止める判断のほうが難しい」だったことだ。

組むのは楽しい。動くと嬉しい。でも、動いたものを止める判断は、組むときの3倍くらい慎重さが要る。サンクコスト、自尊心、未来への期待が、止める判断を曇らせる。

自動化を組もうとしている人へ、最低限これだけ守ればいい:

コストエコノミクスを最初に計算する — 1サイクルのトークン消費 × 月の起動回数 = 月のコスト
モデルはSonnet固定が基本 — Opusは「失敗が信用毀損になる」タスクだけ
追加使用量は常にOFF — 自動化と従量課金は相性が悪い
止める基準を最初から設計する — 動かす設計と同じ重さで考える
「量産」は手段、「価値検証」が目的 — 量産しすぎると目的が見えなくなる

App Factory が動いている間、確かに5本のアプリが手元に揃った。止めた今、磨き込まれているのは2本だけ。でも、その2本のほうが、年間365本の幻想より、よほど確かな資産になっている。

100日前、自分はWebアプリを1個もデプロイしていなかった。

App Factoryで5本量産し、3日で停止し、2本に絞って磨き込んでいる今、業務OSは「動かし続けられる仕組み」に育ってきた。動かし続けられないものは、業務OSじゃない。動かないものは美術品だ。

コードを書ける能力ではなく、コストエコノミクスを設計できる能力が、AIで業務を自動化するときの本当の差分になる。これから組む人は、止める判断を最初から組み込んでおくといい。

「動く」と「回し続けられる」の間には、見えない壁がある。その壁は、コストでできている。