「コードを書くAI」ではなく、「一人会社を24時間動かす社員」として使う
「AIを使って稼ぐ」と聞くと、多くの人は同じことを想像する。
ChatGPTにブログを書かせる。
AIで画像を大量生産する。
生成した動画をTikTokに投稿する。
AIにプログラムを書かせ、アプリを量産する。
しかし、これらの方法だけで大きく稼げるケースは少ない。
なぜなら、AIを使って「作業量」を増やしているだけだからだ。
作れる記事が10本から100本になっても、読者がいなければ売上は増えない。作れるアプリが1個から10個になっても、顧客の悩みを解決していなければ誰も課金しない。
AI時代に本当に強い人は、AIをコンテンツ製造機として使っていない。
会社そのものを小さくするために使っている。
開発者を雇わない。
カスタマーサポートを増やさない。
会議をしない。
仕様書を人間同士で回さない。
ローカル環境から本番環境へ、何段階も受け渡さない。
顧客から要望が届いたら、AIがコードを読み、修正し、テストし、数分後にはユーザーが触れる状態にする。
その極端な実例が、個人開発者のピーター・レベルズだ。
彼のClaude Code活用法を一言で表すなら、こうなる。
Claude Codeを「便利なコーディング補助」ではなく、サーバーの中に住み続ける社員として使う。
この記事では、ピーターが何をしているのかを分解し、日本の個人開発者や小規模事業者でも再現できる形に落とし込んでいく。
ピーター・レベルズとは何者なのか
ピーター・レベルズは、Nomad List、Remote OK、Photo AI、Interior AIなど、複数のインターネットサービスを立ち上げてきた個人開発者だ。
彼が広く知られるようになったきっかけの一つは、「12か月で12個のスタートアップを作る」という企画だった。大きな資金を調達して組織を作るのではなく、サービスを素早く公開し、反応があったものだけを育てるスタイルを続けてきた。
現在の代表的なサービスの一つが、AI写真生成サービスのPhoto AIだ。
ユーザーが自分の写真をアップロードすると、その人物のAIモデルを作り、スタジオ撮影風の写真、プロフィール写真、ファッション写真、旅行写真、動画などを生成できる。Photo AIの公式サイトでは、これまでに3,000万枚以上の写真が生成されたとしている。
そして2026年3月、ピーターはPhoto AIについて、次の数字を公表した。
指標公表値1ドル162円で換算月間売上10万5,000ドル約1,701万円月間利益8万ドル約1,296万円年間売上ペース126万ドル約2億412万円年間利益ペース96万ドル約1億5,552万円
さらに驚くのは、そのサービスの中心部分が、約4万870行の巨大なPHPファイルで動いていると本人が明かしていることだ。
普通のエンジニアが聞けば、眉をひそめるかもしれない。
「そんな巨大ファイルは保守できない」
「マイクロサービスに分けるべきだ」
「もっとモダンなフレームワークを使うべきだ」
だが、売上はコードの美しさに対して支払われるものではない。
ユーザーが欲しい結果を出し、その状態を維持できているなら、技術構成が教科書どおりである必要はない。
ピーターの強さは、最先端の技術を誰よりも多く知っていることではない。
売上につながらない複雑さを、徹底的に捨てていることだ。
厳密には「AIだけ」で稼いだわけではない
ここは誤解してはいけない。
ピーターは、ある日突然Claude Codeを触り始め、AIだけで年1.6億円を稼げるようになったわけではない。
彼には長年の開発経験がある。インターネット上の知名度があり、自分の商品を発信できるフォロワーがいる。市場を選ぶ判断力、価格を決める能力、ユーザーの反応を読む経験もある。
AIがゼロからすべてを生み出したのではない。
AIが、すでに持っていた開発力、判断力、発信力を増幅した。
この違いは大きい。
AIを使えば、経験が不要になるわけではない。むしろAIによって実装速度が上がるほど、「何を作るべきか」「誰に売るべきか」「どこまで作らないか」という判断の価値が高くなる。
だから、この記事の本当のテーマは「Claude Codeにどんな魔法のプロンプトを入れれば億を稼げるか」ではない。
Claude Codeによって、一人の人間が会社レベルの速度で動く仕組みをどう作るかである。
活用法1
Claude Codeをノートパソコンではなく、VPSに住ませる
ピーターの運用で最も特徴的なのは、Claude Codeをローカルのノートパソコンではなく、サービスが稼働しているVPS上で動かしていることだ。
本人によれば、約1年間、ほぼすべてのコーディングをVPS上のClaude Codeで行っている。パソコンを閉じても処理を継続でき、バッテリーも消費せず、別の端末やスマートフォンから作業を引き継げる。新しいサービスも、すでにサーバー上にいる状態から作り始められるため、そのまま公開まで持っていけるという。
一般的な開発フローは、次のようになっている。
企画する。
ローカル環境でコードを書く。
ローカルでテストする。
GitHubにプッシュする。
CIが走る。
ステージング環境に反映する。
確認して本番環境にデプロイする。
大規模な組織では、このプロセスが必要だ。何十人ものエンジニアが同じシステムを触る以上、事故を防ぐための境界線が欠かせない。
だが、一人で運営する小さなサービスに、そのまま大企業の工程を持ち込むとどうなるか。
修正自体は3分なのに、公開まで20分かかる。
細かな面倒が積み重なり、「この変更は後でいいか」という判断が増える。顧客から要望が来ても、修正が翌日、翌週へと先送りされる。
ピーターは、この待ち時間を極端に短くした。
以前はローカルでテストし、GitHub経由で自動デプロイするまで約1分かかっていた。そこからサーバーへ直接プッシュする方式に変えて約3秒になり、現在はClaude Codeがサーバー上で直接コードを変更するところまで進めているという。本人は、12か月の間にサイトが停止したのは2回ほどで、いずれも約10秒だったと述べる一方、大企業ならステージング環境を使うとも明言している。
ここで真似すべきなのは、「全員が本番環境を直接編集しろ」という話ではない。
真似すべきなのは、AIが作業を継続できる場所に置かれていることだ。
自分のパソコン上でClaude Codeを動かしている限り、パソコンを閉じれば作業も止まる。通信が切れれば止まる。別の端末に移れば、再び状況を説明しなければならない。
VPS上の永続セッションで動かせば、AIはプロジェクトのすぐ隣に居続けられる。
これは単なる環境構築の違いではない。
「AIを使う時間」を増やすのではなく、AIが働ける時間を人間の稼働時間から切り離すという発想だ。
活用法2
一つの商品につき、一つの永続セッションを持たせる
ピーターはVPSへの接続にTermiusを使い、サービスごとに接続用のプロファイルを用意している。
接続すると、そのサービスのディレクトリへ移動し、対応するtmuxのセッションへ入る。各セッションではClaude Codeが開いたままになっており、ノートパソコンからでもスマートフォンからでも、同じ作業へ戻れるようにしている。接続やtmuxへの復帰を簡単にするシェル関数自体も、Claude Codeに作らせたという。
この仕組みの重要なところは、ターミナル操作が格好いいことではない。
商品ごとに、専属の作業部屋があることだ。
Photo AIの部屋にはPhoto AIのコードとClaude Codeがいる。
Nomad Listの部屋にはNomad ListのコードとClaude Codeがいる。
Remote OKの部屋にはRemote OKのコードとClaude Codeがいる。
人間が商品を切り替えるときは、その部屋に入るだけでいい。
一般的なチャット型AIでは、会話を始めるたびに説明が必要になる。
「これはこういうサービスです」
「前回ここまで実装しました」
「このファイルは変更しないでください」
「テストはこのコマンドで実行します」
その説明コストが、AI活用の速度を奪う。
一方、プロジェクトのディレクトリ内でClaude Codeを動かし続ければ、AIはコード、設定ファイル、テスト、履歴に直接アクセスできる。人間がゼロから説明しなくても、「今この商品がどうなっているか」を調べられる。
Anthropicの公式ドキュメントでも、Claude Codeは単にコード候補を返すツールではなく、ファイルの読み取り、コマンド実行、コード変更、調査、計画、実装までを進めるエージェント型ツールとして説明されている。
つまり、Claude Codeの強みを引き出すには、毎回コード断片をチャット欄に貼るのではなく、商品全体へアクセスできる場所で働かせる必要がある。
活用法3
「コードを書いて」ではなく、「完了状態」を渡す
Claude Codeを使っても成果が出ない人は、指示の出し方が細かすぎるか、逆に曖昧すぎる。
たとえば、こんな依頼だ。
ログイン画面を改善してください。
これでは、何をもって改善なのか分からない。
デザインを変えるのか。
エラー表示を変えるのか。
ログイン速度を上げるのか。
Googleログインを追加するのか。
離脱率を下げたいのか。
逆に、コードの一行一行まで指示するのも効率が悪い。
このファイルの35行目に関数を追加して、次にこの変数名を変更して……。
これではClaude Codeを、自分より入力速度の速いキーボードとしてしか使えていない。
渡すべきなのは、作業手順ではなく完了条件だ。
実務では、次のような形が使いやすい。
目的:
ログイン時のエラーによる離脱を減らす。
現状:
パスワードが間違っている場合も、通信エラーの場合も、
同じ「ログインに失敗しました」が表示される。
変更範囲:
ログイン画面、認証API、関連テスト。
完了条件:
- 入力ミスと通信障害で異なるメッセージが表示される
- メールアドレスの存在有無は外部に漏らさない
- 既存のGoogleログインは壊さない
- スマートフォン表示でもレイアウトが崩れない
- 関連テストがすべて通る
禁止事項:
- データベース構造を変更しない
- 認証ライブラリを新しく追加しない
作業後:
- 変更したファイルを要約する
- 実行したテストを示す
- 残っているリスクを報告する
この形式なら、Claude Codeはコードベースを調査し、自分で変更箇所を探し、実装方法を考えられる。
人間の役割は「どう書くか」から、「どの状態になれば価値があるか」へ移る。
ここで、経営と開発がつながる。
良い完了条件を書くには、顧客が何に困っているのかを理解していなければならない。技術だけを見ている人より、顧客の行動、課金理由、離脱理由を見ている人のほうが、Claude Codeに価値のある仕事を渡せる。
AI時代に重要なのは、プロンプトの語彙力ではない。
完了状態を定義する力だ。
活用法4
CLAUDE.mdを「一人会社の業務マニュアル」にする
Claude Codeには、プロジェクト固有の指示をCLAUDE.mdへ保存する仕組みがある。
公式ドキュメントでは、CLAUDE.mdは会話の開始時に読み込まれるため、ビルドやテストのコマンド、コーディング規約、作業ルールなどを記載できると説明されている。ただし、長大な説明書にするのではなく、コードを読めば分かることは書かず、短く具体的に保つことが推奨されている。
多くの人は、ここにインデント幅や変数名の規則だけを書く。
だが、一人会社で本当に重要なのは、コードスタイルよりも商売上の優先順位だ。
たとえば、次のように書ける。
Product goal
- このサービスは、個人事業主が10分以内に商品写真を作るためのもの。
- 機能数より、初回生成までの速さを優先する。
- 無料ユーザーの利用量を増やす変更は、原価への影響を必ず確認する。
Architecture
- PHP、JavaScript、PostgreSQLを使用。
- 新しいフレームワークは、明示的な許可なしに追加しない。
- 既存の仕組みで解決できる場合は依存関係を増やさない。
Workflow
- 変更前に関連コードとテストを読む。
- 大きな変更は、実装前に計画を提示する。
- 変更後はテスト、静的解析、主要画面の確認を行う。
- 失敗したテストを削除して解決したことにしない。
Safety
- 本番データを削除しない。
- データベース変更にはロールバック手順を付ける。
- APIキーや個人情報をログへ出力しない。
- 課金、認証、削除機能は特に慎重に扱う。
Definition of done
- ユーザーから見た変更内容を説明できる。
- テスト結果を報告する。
- 変更したファイルを一覧にする。
- 既知のリスクと未対応事項を明記する。
これがあるだけで、毎回同じ注意を繰り返す必要がなくなる。
さらに重要なのは、Claude Codeが失敗したときの扱いだ。
「また同じミスをした」と怒って終わるのではなく、再発防止ルールをCLAUDE.mdに追加する。
本番環境の設定ファイルまで変更してしまったなら、「設定ファイルは明示的な許可なしに変更しない」と書く。
テストを通すために重要な検証を削除したなら、「失敗したテストの削除は禁止」と書く。
関係のないファイルまで整形して差分が巨大になったなら、「依頼と無関係なリファクタリングをしない」と書く。
Anthropicも、繰り返し発生するミスや、何度も説明している内容は、永続的な指示へ追加するサインだとしている。
つまりCLAUDE.mdは、単なるAI向け設定ファイルではない。
一人会社に蓄積される、失敗と判断のデータベースだ。
社員を雇う会社では、知識を研修資料や社内Wikiへ蓄積する。
一人会社では、それをClaude Codeへ読ませる。
活用法5
承認作業を減らす代わりに、ガードレールを増やす
ピーターはClaude Codeの権限確認を大幅に省略するモードを使い、サーバー上で高速に作業している。
本人は、この運用に変えてから開発速度が一気に上がり、タスクボードが初めて空になった、通常の約10倍の出力ができた、と述べている。認証やセキュリティの改修、画像機能、動画・音声機能、3Dビューアー、ニュースレター、チャットボット、電子書籍生成など、複数の商品にまたがる変更を短期間で進めたという。
ただし、この部分をそのままコピーするのは危険だ。
Claude Codeの公式ドキュメントでは、権限確認を飛ばすbypassPermissions相当の運用は、隔離されたコンテナや仮想マシンなど、外部の安全境界がある場合に限って使用すべきだと明記されている。確認を省略した瞬間、最後の防御線は実行環境の隔離だけになるからだ。
日本の個人開発者が取り入れるなら、ピーターの運用をそのまま再現するのではなく、次のように翻訳したほうがいい。
調査段階ではPlanモード
まずコードを変更させず、関連ファイル、影響範囲、実装方針、リスクを調べさせる。
特に課金、認証、データ削除、メール配信など、事故の影響が大きい部分は、いきなり実装させない。
実装はステージング環境で自動化
本番と似た構成のステージング環境を用意し、そこでClaude Codeに変更とテストを進めさせる。
すべてのコマンドを毎回承認するのではなく、許可する操作と拒否する操作をあらかじめ分ける。
公式ドキュメントには、変更を許可するacceptEdits、安全性を自動判定するauto、計画だけを作らせるplanなど、複数の権限モードが用意されている。コマンド単位でもallow、ask、denyを設定できる。
本番反映には一つだけ人間の関門を残す
テストが通った。
画面確認が終わった。
差分が想定範囲内だった。
ロールバック方法がある。
この状態になったら、人間が本番反映を許可する。
重要なのは、人間がすべてのコードを一行ずつ書くことではない。
壊れたときに戻せる構造を作り、人間は最後の不可逆な判断だけを担当することだ。
活用法6
コードレビューより、テストとロールバックを重視する
AIが大量のコードを書くようになると、すべてを人間が一行ずつ確認する方法は限界を迎える。
10倍の速度でコードが生成されても、レビューに10倍の時間がかかれば、生産性は上がらない。
そこで必要になるのが、信頼の置き場所を変えることだ。
「Claudeが正しいコードを書いたはずだ」と信じるのではない。
「間違っていればテストが落ちる」
「主要なユーザー操作を自動で確認できる」
「問題があればすぐ前の状態へ戻せる」
この仕組みを信頼する。
ピーター自身も、すべてを細かく確認するよりテストを用意し、本番で素早く確認するフィードバックループを重視している。また、サーバーにはオンサイトとオフサイトを組み合わせた複数のバックアップを持たせていると説明している。
安全なClaude Code運用では、少なくとも次の四つを先に作る。
- 主要機能の自動テスト
- 本番前の動作確認
- エラーと売上異常を検知する監視
- 数分で以前の状態へ戻せるロールバック
Claude CodeのHooksを使えば、ファイル変更後にテストやフォーマッターを実行する、特定の操作前に検査を入れる、といった処理も自動化できる。Hooksは、Claude Codeの特定のライフサイクルでシェルコマンド、HTTP処理、LLM判定などを実行する公式機能だ。
たとえば、変更後に次の流れを自動実行する。
コード変更
↓
自動テスト
↓
静的解析
↓
主要ページの動作確認
↓
差分の要約
↓
問題がある場合は本番反映を停止
これにより、人間の仕事は「全部を見る」から「異常だけを見る」へ変わる。
一人で大きく稼ぐ人は、仕事を速くこなしているだけではない。
確認が必要な仕事そのものを減らしている。
活用法7
顧客の要望を、そのままClaude Codeの作業キューにする
ピーターが公開している一人会社の構成では、ユーザーからの要望を集めるフィードバックボード、Stripeの顧客向け請求管理画面、ユーザー自身で操作できる返金機能、ChatGPT APIなどを使った自動処理を組み合わせている。
本人が示す理想形は「創業者1人、人間0人」で、マーケティング、開発、デザインを自分が担当し、それ以外を可能な限り自動化するモデルだ。
ここでClaude Codeは、単に新機能を作るためだけに使われない。
顧客の声を、売上につながる改善へ変換する装置になる。
たとえば、次のような流れだ。
ユーザーが要望を投稿
↓
同様の要望を分類
↓
解約率・課金率への影響を確認
↓
価値が高いものを一件選ぶ
↓
Claude Codeが影響範囲を調査
↓
実装・テスト
↓
ユーザーへ改善を通知
この仕組みを作ると、タスク管理の意味が変わる。
多くの会社では、要望を受けてから会議をし、仕様書を書き、担当者を決め、スプリントへ入れ、数週間後にようやく公開する。
一人会社なら、その日のうちに出せる可能性がある。
小さな会社が大企業に勝てるのは、機能数ではない。
顧客の声が商品へ反映されるまでの時間だ。
Claude Codeを導入したのに、相変わらず人間がタスクを細かく分解し、コードをコピペし、変更箇所を一つずつ指定しているなら、AIの速度を活かせていない。
顧客の問題と完了条件を渡し、Claude Code自身にコードベースを調べさせる。
これが、チャットボットとしての利用と、社員としての利用の違いである。
活用法8
あえて技術構成を複雑にしない
Photo AIの中心部分が4万行を超える一つのPHPファイルであることは、すべての開発者が巨大ファイルを作るべきだという意味ではない。
むしろ、表面的な形を真似すると危険だ。
ピーターにとって重要なのは、PHPであることでも、巨大ファイルであることでもない。
重要なのは、自分とClaude Codeが全体を把握できる範囲に、システムを留めていることだと考えられる。
これは公開情報からの解釈だが、商品を細かなサービスへ分割しすぎると、変更のたびに複数のリポジトリ、API、認証方式、デプロイ手順をまたぐことになる。
人間にとって複雑なシステムは、AIにとっても複雑だ。
コンテキストへ読み込むファイルが増える。
どこを変更すべきかの調査に時間がかかる。
片方だけ更新して不整合が起きる。
テスト範囲が広がる。
障害時に原因を特定しにくくなる。
Claude Codeがあるからといって、無限に複雑な技術構成を管理できるわけではない。
AIは複雑さのコストを下げるが、ゼロにはしない。
だから新しいライブラリ、新しいサービス、新しいデータベース、新しいフレームワークを導入するときは、こう考える。
この技術は、顧客が受け取る価値を増やすのか。 それとも、開発者が技術的に満足するだけなのか。
年商2億円規模の商品を作った人が、必ずしも最もモダンな構成を選んでいない。
これは、多くの個人開発者にとって重要な事実だ。
活用法9
Claude Codeに「開発」ではなく「会社の自動化」を作らせる
AIコーディングツールを使う人の多くは、商品機能の実装だけを考える。
しかし、一人で大きく稼ぐために必要なのは、商品を作ることだけではない。
問い合わせへの対応。
不正利用の検知。
請求情報の変更。
返金。
解約。
コンテンツの審査。
障害の通知。
定期レポート。
売上集計。
顧客への案内。
事業が成長すると、こうした運営業務が増える。
売上が2倍になったとき、問い合わせも2倍になり、人手も2倍必要になるなら、一人会社は維持できない。
ピーターが公開している構成では、Stripeの顧客向け機能やセルフサービスの管理画面、自動返金、AI APIを使うワーカースクリプトなどによって、人間が介在する箇所を減らしている。
Claude Codeに作らせるべきものは、新しい派手な機能だけではない。
「毎週自分が30分かけている仕事」をなくすコードだ。
たとえば、毎朝売上を確認してSlackへ書いているなら、自動レポートを作る。
同じ質問への問い合わせが多いなら、管理画面やヘルプページを改善する。
返金依頼のたびに管理画面を操作しているなら、条件付きのセルフ返金を作る。
不正利用を目視確認しているなら、異常値を検知し、人間には判断が必要なケースだけを送る。
一つひとつは小さな自動化でも、積み重なると会社の固定費が変わる。
売上を増やす機能と同じくらい、自分の作業を消す機能を作る。
これが、一人で利益を残すためのClaude Code活用法だ。
活用法10
Claude Codeをバックグラウンドの作業者にする
Claude Codeは、対話画面を見ながら使うだけではない。
公式には、claude -pなどを使った非対話実行や、許可するツールを限定した実行、構造化された出力、セッションの継続などが用意されている。CIやスクリプトから呼び出し、バックグラウンド処理へ組み込むことも想定されている。
これを使うと、人間が会話を開始しなくても仕事を発生させられる。
たとえば毎晩、次の処理を実行する。
- 直近24時間のエラーログを確認
- 同じ原因と思われるエラーを分類
- 再現方法を調査
- 修正案を作成
- ステージング環境で修正
- テストを実行
- 翌朝、人間へ差分とリスクを報告
あるいは、ユーザーから届いた問い合わせを分析させる。
- 問い合わせをテーマ別に分類
- 件数と売上影響を集計
- 商品上の原因で解決できるものを抽出
- 改善候補を優先順位順に並べる
- 上位一件の実装計画を作る
ここまで来ると、Claude Codeは「人間が話しかけたときだけ答えるAI」ではない。
夜の間に調査を済ませ、朝になると判断材料を用意しているスタッフになる。
ただし、バックグラウンドで動かすほど、安全設計は重要になる。
削除、送金、請求、顧客への一斉送信、本番データの変更など、取り返しのつかない操作は自動化の範囲から外す。
AIへ渡す自由度と、失敗時の被害範囲をセットで考えなければならない。
最大の秘密
Claude Codeで開発速度を上げても、客は増えない
ピーターの発信で、最も重要なのは技術の話ではない。
彼は、複雑なAIエージェント環境や「AI開発工場」を作ることに夢中になりながら、売上もアクセスもない個人開発者が多いと指摘している。開発環境を作り込むことで満足し、マーケティングを後回しにしているという趣旨だ。
さらに、AIによって誰でもアプリを作れるようになるほど、本当の課題は流通、つまり顧客へ届ける力になるとも述べている。
すでに多くの人へ情報を届けられるのか。
広告費を使えるのか。
UGCを生み出せるのか。
無料で話題を作る発想があるのか。
開発が簡単になった分、こうした配信能力の差が大きくなる。
これはAI時代の残酷な現実だ。
Claude Codeを導入すると、機能は速く作れる。
しかし、開発速度が10倍になっても、アクセスがゼロなら売上はゼロだ。
むしろ危険なのは、作れる速度が上がることで、需要のない機能を大量生産してしまうことだ。
機能を追加するたびに、コード量、テスト、障害リスク、問い合わせ対応が増える。
客が増えていないのに、保守するものだけが増える。
だから、Claude Codeで生まれた時間の半分は、開発以外に使わなければならない。
顧客へ話を聞く。
競合商品のレビューを読む。
購入されない理由を調べる。
価格をテストする。
販売ページを書き直す。
事例を公開する。
SNSで制作過程を発信する。
ユーザーが他人へ紹介したくなる仕組みを作る。
Claude Codeの本当の価値は、コードを書く時間を短くすることではない。
人間が、顧客と市場について考える時間を取り戻すことだ。
日本の個人開発者が再現する30日間プラン
ピーターと同じ経験、知名度、フォロワーを持っていなくても、運営の考え方は取り入れられる。
ただし、最初から複数サービスを作ってはいけない。
まず一つの商品、一つの顧客、一つの問題に絞る。
1週目：コードを書く前に、支払う人を探す
最初の1週間で作るのは、完成したサービスではない。
誰の、どんな問題を、いくらで解決するかを決める。
対象は広げない。
「すべての会社向けAIツール」ではなく、「不動産会社が物件紹介文を10分で作るツール」のように絞る。
候補となる顧客へ話を聞き、現在どんな方法で対応しているか、何分かかっているか、どれくらい困っているかを確認する。
そして簡単な販売ページを作る。
無料登録ボタンだけではなく、可能なら価格を表示する。事前登録、予約、少額の先行購入など、ユーザーが本当に行動する仕組みを置く。
この段階で反応がなければ、Claude Codeに大量の機能を作らせても状況は変わらない。
2週目：一つの価値だけを提供する
次の1週間で、ユーザーが料金を払う中心機能だけを作る。
ログイン、管理画面、詳細なプロフィール設定、多数のテンプレート、チーム機能などは、必要になるまで後回しにする。
Claude Codeには、まず既存の構成を調査させ、実装計画を作らせる。
計画を確認したら、ステージング環境で実装とテストを進めさせる。
この段階で必ず入れるものは、アクセス解析、課金、エラー監視、問い合わせ窓口だ。
売上を確認できない商品は、事業ではない。エラーを確認できない商品は、自動運転できない。
3週目：Claude Codeが迷わない環境を作る
3週目は、新機能を増やすより運営基盤を整える。
CLAUDE.mdに、商品の目的、技術構成、禁止事項、テスト方法、完了条件を書く。
一つの商品につき、一つのVPSまたは安全な開発環境、一つの永続セッションを用意する。
Claude Codeが変更を加えたら、テスト、静的解析、主要画面の確認が自動で走るようにする。
バックアップとロールバックも確認する。
ここで目指すのは「AIを全面的に信用すること」ではない。
AIが間違えても、事業が致命傷を負わないことだ。
4週目：開発と同じ時間を販売へ使う
最後の1週間は、毎日一つだけ改善を公開する。
ただし、改善内容は自分の思いつきで決めない。
問い合わせ、離脱地点、決済直前の行動、解約理由など、ユーザーの反応から決める。
午前中に、最も売上への影響が大きい問題を一件選ぶ。
Claude Codeへ調査と実装を依頼する。
テスト後に公開する。
午後は、その改善を顧客へ知らせる。
改善したことを発信すれば、それ自体がマーケティングになる。
「開発しています」と言うより、「昨日届いた要望を今日反映しました」と見せたほうが、商品の速度と信頼が伝わる。
一人会社を動かす毎日のループ
Claude Codeを導入した後は、タスクを大量に登録するのではなく、次のループを毎日回す。
朝：数字を見る
売上、登録数、有料転換率、解約、エラー、問い合わせを見る。
コードではなく、事業の状態から一日を始める。
午前：一番価値の高い問題を一件選ぶ
十件の細かなタスクではなく、一件を選ぶ。
判断基準は「面白いか」ではなく、売上、継続率、利用成功率へ与える影響だ。
昼：Claude Codeへ完了条件を渡す
関連コードを調査させ、計画を確認する。
その後、実装、テスト、差分要約まで進めさせる。
人間は作業手順を細かく指示するのではなく、顧客にとっての正解を伝える。
午後：公開し、顧客へ届ける
改善を公開したら終わりではない。
該当する要望を送ったユーザーへ知らせる。SNSで制作過程を共有する。販売ページへ反映する。事例にする。
開発物を、必ず流通へ接続する。
夜：一日の失敗をルールに変える
Claude Codeが迷った箇所、余計な変更をした箇所、人間が何度も説明した内容を確認する。
必要ならCLAUDE.mdへ短いルールを追加する。
毎日少しずつ、AIが自社に最適化されていく。
絶対に真似してはいけないこと
ピーターの事例は刺激的だが、表面だけをコピーすると失敗する。
いきなり本番環境で自由に操作させる
本番データ、課金、認証、顧客への通知を扱う環境で、権限確認をすべて飛ばすのは危険だ。
まずは隔離された開発環境かステージング環境で運用し、許可する操作を限定する。公式ドキュメントも、権限確認を省略するモードにはコンテナやVMなどの隔離が必要だとしている。
巨大なPHPファイルだけを真似する
4万行のファイルが売上を生んだわけではない。
ピーターが自分で理解し、素早く変更できる構成を選んだ結果である。
技術構成は、自分の商品、経験、利用者数、障害リスクに合わせるべきだ。
需要を確認せず、AIで大量開発する
開発費が下がると、作る判断が甘くなる。
「すぐ作れるから作る」のではなく、「料金を払う顧客の問題だから作る」。
Claude Codeへ依頼する前に、その変更がどの数字を改善するのかを決める。
売上を利益や個人所得と混同する
月商10万5,000ドルと、月間利益8万ドルは別の数字だ。
さらに、事業利益と個人の手取りも同じではない。税金、決済手数料、インフラ費用、AI API費用、返金などの扱いによって変わる。
大きな数字を見るときほど、「売上」「粗利益」「営業利益」「個人所得」のどれなのかを確認する必要がある。
AIが事業判断まで正しく行うと思い込む
Claude Codeはコードベースを調査し、実装案を作り、テストを実行できる。
しかし、その機能が本当に必要か、価格をいくらにするか、どの顧客を狙うかは、コードだけを読んでも分からない。
市場の判断まで丸投げした瞬間、他のAI利用者と同じ平均的な商品になる。
億を生んでいるのは、秘密のプロンプトではない
ピーター・レベルズのClaude Code活用法を見て、「自分も同じプロンプトを使えば稼げる」と考えるのは間違いだ。
秘密はプロンプトにない。
VPSにClaude Codeを置く。
商品ごとに永続セッションを持たせる。
完了条件を渡す。
判断基準をCLAUDE.mdへ蓄積する。
テストとバックアップで失敗に備える。
顧客の要望を、すぐ商品へ反映する。
自分が繰り返している運営業務を自動化する。
浮いた時間をマーケティングへ使う。
これらを一つのシステムとして組み合わせていることが強さだ。
Claude Codeの価値は、コードを速く書けることではない。
次のループを、極端に短くできることにある。
顧客が困る ↓ 原因を理解する ↓ 修正する ↓ 公開する ↓ 結果を測る
普通の会社で数週間かかるループを、一人で一日、場合によっては数時間で回す。
この速度が何か月も積み重なれば、商品の差は大きくなる。
ただし、AIが作るのは供給であって、需要ではない。
誰の問題を解くのか。
なぜ料金を払うのか。
どうやって存在を知ってもらうのか。
競合ではなく自分の商品を選ぶ理由は何か。
この答えは、人間が見つけなければならない。
AI時代に「海外の天才しかやっていないこと」は、難解なプロンプトを書くことではない。
AIに仕事を奪われる前に、AIを使って会社から仕事そのものを消していることだ。
そして、消えて生まれた時間を、さらにコードを書くためではなく、顧客を理解し、商品を売るために使っている。
だから一人でも、年商2億円、年間利益ペース1.6億円という事業を動かせる。
Claude Codeは、億を稼がせてくれる魔法の道具ではない。
しかし、正しい顧客、正しい商品、正しい販売力を持つ人にとっては、一人の判断力を会社規模へ増幅する装置になる。
