Claude Codeで個人開発を週末に公開する：副業につなぐ現実手順

土曜の朝、コーヒーを淹れて「よし今日こそアプリを公開するぞ」と意気込む。そして日曜の夜、手元に残っているのは8割完成の管理画面と、ログイン機能の途中までと、増えただけのブラウザのタブ。

僕はこのパターンを、たぶん20回はやりました。

詰まっていたのは、実は実装じゃないんです。「何を作るか」「どこまでで公開するか」「いつ手を止めるか」——この“決める作業”でエネルギーを使い果たして、肝心の公開までたどり着けない。Claude Codeを使い始めて変わったのは、コードを速く書けるようになったことより、この決める作業をAIに半分肩代わりさせて、週末のうちに「とりあえず公開」までたどり着けるようになったことでした。

この記事の要点

• Claude Codeは「丸投げで稼ぐ道具」ではない。1人の開発を企画・設計・実装・継続・公開の5役に分けて、小さく渡すと失敗しにくい。
• 最初の30分はコードを書かない。**作業場の準備とCLAUDE.md**に使うほうが、結局いちばん速い。
• 週末は「機能を増やす」より「公開まで進める」。土曜にMVPを1画面へ削り、日曜に出す設計にする。
• 続かない原因は「前回どこまでやったか忘れる」こと。Obsidianの作業ログをClaude Codeに渡して次回タスクへ変換すると、再開コストが激減する。
• 収益化はSaaSから始めない。学習ログ→教材、週末アプリ→ポートフォリオ、社内の手作業→受託メニューの順が現実的。

個人開発がきついのは「実装」じゃなくて「決めること」だった

最初に正直なところを書きます。Claude Codeは魔法ではありません。「いい感じのSaaS作って稼げるようにして」と頼んで、翌朝に通帳が潤っている、みたいなことは起きない。

でも、個人開発で本当にしんどいのはコードを書く時間じゃないんですよね。何を作るか、どの機能を捨てるか、デザインはどうするか、いつ公開に踏み切るか。この判断が積み重なって、土曜の午前中だけで燃え尽きる。僕の場合、手が止まる原因の9割はこっちでした。

Claude Codeが効くのは、まさにこの「決める作業」を一緒に進めてくれるところです。公式のCommon workflowsを見ても、コード生成だけじゃなく、コードの理解、テスト、PR作成、ドキュメント化、ノート整理まで守備範囲に入っている。つまり、相棒として一番頼れるのは「実装の手前と後ろ」なんです。

まだClaude Codeを触り始めたばかりなら、先にClaude Codeの始め方ガイドでインストールと初回操作を済ませてから、この先の30分メニューに進んでください。道具の使い方と使いどころは別の話なので、両方そろって初めて回り始めます。

1人開発を5つの役割に分けて、小さく渡す

Claude Codeを「コードを書くAI」とだけ思っていると、期待値がずれます。「全部作って」と渡すと、たいてい自分が読めないコードの山が返ってきて、結局メンテできずに放置する。僕が何度もやった失敗です。

そこで、自分1人のプロジェクトを次の5役に分けて、1つずつ小さく渡すようにしました。

役割	Claude Codeに任せること	自分が決めること
企画	MVPの整理、機能の優先順位づけ、競合を見る観点	誰のどんな困りごとを解くか
設計	ディレクトリ構成、データの持ち方、画面の流れ	どこまでシンプルに割り切るか
実装	画面、API、テスト、修正案	どの案を採用するか
継続	CLAUDE.mdの更新、Obsidianメモ、次回タスク化	何を続けるか
公開	README、公開前チェック、導線の文言	売り方と価格

コツは、最初から完成品を頼まないことです。「まず編集せずに計画して」「最小構成だけ作って」「公開前チェックだけして」と、役割を切って渡す。こうすると一回ごとの出力が短くなって、中身を自分で追える。自分が読めて直せる範囲を超えないことが、個人開発で運用を続ける生命線です。

最初の30分：コードを書かず、作業場を整える

ここが一番つまずきやすいので丁寧に書きます。初回の30分でやるのは、アプリを完成させることではありません。Claude Codeが迷わず動ける作業場を作ることです。逆です、と言いたくなるくらい、最初に手を動かしたい衝動をぐっとこらえる。

まず小さな実験フォルダを用意します。

mkdir claude-weekend-lab
cd claude-weekend-lab
git init
npm create vite@latest app -- --template react-ts
cd app
npm install
claude

Claude Codeが立ち上がったら、最初のプロンプトはこれで十分です。

まずファイルを編集せずに、このプロジェクトの構成を確認してください。
私は週末に公開できる小さな個人開発アプリを作りたいです。

条件:
- 初心者でも理解できる構成にする
- 2日でMVPを公開する
- 認証や決済は最初は入れない
- 最初にREADME、画面一覧、タスク一覧を提案する
- 実装に入る前に、変更予定ファイルを一覧で確認する

ここで「まず編集せずに」と一言入れるのが効きます。これを書かないと、初心者ほどAIにいきなり大量のファイルを書き換えさせて、5分後には自分のプロジェクトで何が起きているのか分からなくなる。最初は計画だけ出させて、自分が納得した範囲だけ実装させる。この順番を守るだけで、土曜の午前が「謎のデバッグ大会」になるのを防げます。

CLAUDE.md：毎回おなじ説明をしないための足場

毎回チャットに「Reactで、TypeScriptで、初心者向けに、勝手に大規模化しないで」と打ち込むの、地味に消耗します。3回目くらいで嫌になる。

これを解決するのがCLAUDE.mdです。Claude CodeのMemory公式ドキュメントで説明されている、プロジェクトの記憶ファイル。プロジェクト直下に置いておくと、Claude Codeが毎回これを読んでから動いてくれます。個人開発だと、これが想像以上に効きます。

まずは短く、こんなところから始めます。

# Claude Code 個人開発ルール

## 目的
- 週末に公開できる小さなWebアプリを作る
- 学習ログ、ポートフォリオ、将来の商品化に使える状態にする

## 技術方針
- TypeScriptを使う
- UIはシンプルにする
- 依存ライブラリは増やしすぎない
- 認証、決済、複雑なDBはMVP後に検討する

## Claude Codeへの依頼ルール
- 変更前に作業計画を出す
- 変更ファイルを明記する
- 実装後に確認コマンドを提示する
- 初心者にも分かる言葉で理由を書く

## 公開前チェック
- npm run build が通る
- スマホ表示で横スクロールが出ない
- READMEに使い方を書く
- 問い合わせ、商品、実績ページへの導線を確認する

最初から長文にしないでください。守られなくなります。僕は欲張って50行くらいのルールを書いたら、肝心の指示が埋もれてClaude Codeに無視されました。短いほど守られる。慣れてきたら、CLAUDE.mdのベストプラクティスを見ながら、このプロジェクトでしか効かないルールだけを足していきます。

週末プロジェクト：2日で「公開」までたどり着く設計

ここからが本番です。週末プロジェクトは「機能を増やす」より「公開まで進める」を優先します。収益化を狙うなら、未公開の高機能アプリより、荒削りでも人に見せられる小さな成果物のほうが圧倒的に強い。見せられないものは、存在しないのとほぼ同じだからです。

土曜午前：MVPを1画面に削る

最初にClaude Codeにさせるのは「削る仕事」です。作る前に、捨てるものを決める。

このアイデアを2日で公開できるMVPに削ってください。

アイデア:
副業アイデアを入力すると、週末に作れるタスクへ分解するWebアプリ。

出してほしいもの:
1. MVPに入れる機能
2. 後回しにする機能
3. 画面構成
4. データ構造
5. 今日の実装順

ポイントは「後回しにする機能」を必ず出させること。これを言語化しておかないと、土曜の午後に「やっぱり通知機能も欲しいな」と寄り道して、また日曜の夜に未完成のまま終わります。後回しリストは、未来の自分への安全柵です。

土曜午後：動く骨組みだけ作る

計画ができたら、実装の範囲をかなり狭く指定します。

MVPの最初の1画面だけ実装してください。

条件:
- 入力フォーム
- 結果表示エリア
- ローカル状態だけで動く
- API、DB、認証はまだ入れない
- スマホ幅でも崩れない
- 実装後に npm run build を実行して、失敗したら直す

副業化したいときほど、最初からAPI・DB・認証・決済を盛り込みたくなる。でも逆効果です。まず「誰かに見せて反応をもらえる画面」を1枚作るほうが、検証は何倍も速い。バックエンドは反応を見てからで間に合います。

日曜午前：3つの実例で破綻しないか試す

作った画面は、最低3つの実例に通して破綻しないかを見ます。1パターンだけだと、自分に都合のいい入力でしか試さないので、公開後に必ずボロが出ます。

実例	入力例	見るポイント
学習用	Reactを勉強したい初心者	説明が難しすぎないか
副業用	整体院の予約LPを作りたい	具体的な成果物に落ちるか
自分用	Obsidianのメモを整理したい	継続タスクが出るか

Claude Codeにはこう頼みます。

このアプリを3つのユーザーケースでレビューしてください。
初心者の学習、店舗向け副業、自分用メモ整理の3パターンです。

見てほしい点:
- 途中で迷う文言がないか
- 結果が抽象的すぎないか
- スマホで使いにくい部分がないか
- 公開前に直すべき優先順位

ObsidianとClaude Codeで「続ける」仕組みを作る

個人開発が止まる一番の理由、何だと思いますか。僕の場合は、翌週に再開したとき「先週、どこまでやったんだっけ」を思い出すのに30分かかって、その30分でやる気が消えることでした。

これはObsidianの作業ログで解決します。仕掛けは単純で、Obsidian側に日報を書き、Claude Codeに次回タスクへ変換させるだけ。

Obsidianには、たとえばこんなメモを残します。

# 2026-06-01 週末アプリ作業ログ

## 今日できたこと
- Vite + ReactでMVP画面を作成
- 入力フォームと結果表示を実装
- スマホ表示の余白を調整

## 詰まったこと
- 結果文が抽象的で、使う人が次に何をすればよいか分かりにくい
- 料金ページへの導線が弱い

## 次にやること
- 3つの実例で文言を検証
- 公開前チェックを通す
- 商品ページへのリンクを追加

次にClaude Codeを開いたら、このメモを渡して再開します。

この作業ログを読んで、今日の90分で終わるタスクに分解してください。
優先順位は、公開に近づくものを上にしてください。
実装に入る前に、変更予定ファイルと確認コマンドを出してください。

これだけで「思い出す時間」がほぼゼロになります。会話が長くなって迷子になってきたら、Claude Codeのコンテキスト管理のテクニックも合わせて使うと、再開がさらに軽くなります。

公開前チェック：機械でわかる部分は機械に任せる

初心者の個人開発でも、公開前チェックだけは省かないほうがいい。「人に見せて恥ずかしくない最低ライン」を、自分の気力に頼らず、毎回おなじ品質で通すためです。

僕は機械でわかる部分はスクリプトに固定しました。プロジェクトにこんなチェック用スクリプトを置きます。

# scripts/check-before-publish.ps1
$ErrorActionPreference = "Stop"

npm run build
git diff --check
git status --short

Write-Host "Build and whitespace check completed."

実行はこれだけです。

powershell -ExecutionPolicy Bypass -File scripts/check-before-publish.ps1

ビルドが通るか、空白の壊れがないか、コミットし忘れがないか。この辺は人間がやると必ず見落とすので、コマンドに任せます。そのうえで、人間の目が要る部分だけClaude Codeにレビューさせます。

公開前レビューをしてください。

確認してほしい点:
- 初心者が最初の画面で何をすればいいか分かるか
- スマホ表示で横スクロールや文字のはみ出しがないか
- READMEのセットアップ手順が実行可能か
- 個人情報やAPIキーが含まれていないか
- 商品ページ、相談ページ、問い合わせへの導線が自然か

修正が必要な場合は、重要度A/B/Cで並べてください。

副業目的なら、ここで必ず「導線」を見ます。読者が画面を見たあと、次に何をすればいいのか分からない——これが一番もったいない。導線のない公開は、玄関を作らずに家を建てるようなものです。

収益化の導線：最初から大きく売ろうとしない

収益化を狙うとき、いきなり月額SaaSを作りたくなります。でも、僕の実感では遠回りです。小さな商品や相談導線から始めるほうが、現実的にお金につながる。具体的には次の3つの道があります。

道1：学習ログを教材に変える

勉強した内容を、記事・テンプレート・チェックリストに変えます。アクセスが多い記事の下に、関連するミニ商品を置く。たとえばこんなものです。

• 「Claude Code初回セットアップチェックリスト」
• 「個人開発CLAUDE.mdテンプレート」
• 「週末MVP設計シート」

記事を書いて終わりにせず、商品ページへ自然につなげる。学習の副産物がそのまま商品になるので、在庫リスクもありません。

道2：週末アプリをポートフォリオにする

完成したアプリは、そのまま営業資料になります。トップページに「何を解決するか」「画面」「料金」「よくある質問」を置くと、相談につながりやすい。店舗向けの予約LP、小さな管理画面、Obsidian整理テンプレートあたりは、実績として見せやすいジャンルです。

道3：本業の手作業を受託メニューにする

本業で困っている手作業を、小さなツールにします。CSV整形、請求書チェック、議事録整理、問い合わせ分類。最初から汎用SaaSにせず、固定価格の受託メニューにすると検証が速い。「これいくらでやります」と言える形にしておくと、相談が来たときに話が早いです。

よくある質問

Claude Codeは無料で個人開発に使えますか

Claude Code自体はClaudeの有料プランやAPIの利用が前提で、完全無料ではありません。ただ個人開発の検証なら、まず小さなプロジェクトで試して、使う頻度に見合うか確かめてから本格運用に移るのが安全です。最新の料金や対応プランは必ず公式ドキュメントで確認してください。

プログラミング初心者でも個人開発に使えますか

使えますが、「AIに全部任せて自分はコードを読まない」のだけは避けてください。実装後に「この変更を初心者向けに説明して」と聞いて、最低限ロジックを追える状態を保つこと。自分が読めないコードは、次の改修で必ず詰まります。

どんなアプリから作り始めるのがいいですか

「失敗しても痛くない、小さくて公開できるもの」が鉄板です。入力して結果が出るだけの1画面ツール、自分用のメモ整理、店舗向けの簡単なLPなど。最初から認証や決済の要るアプリを選ぶと、公開がどんどん遠のきます。

副業として成立させるには何から始めればいいですか

いきなり月額SaaSを目指さないことです。学習ログを教材にする、週末アプリをポートフォリオにする、本業の手作業を固定価格の受託にする——この3つのどれかから始めるのが現実的です。小さく売って反応を見るほうが、検証が速く失敗も安く済みます。

週末だけの開発で本当に公開までいけますか

機能を欲張らなければ届きます。コツは土曜の午前に「後回しにする機能」を決め切ること。1画面に絞り、API・DB・認証を後回しにすれば、2日で「人に見せられる状態」までは十分到達できます。

実際に試した結果

このサイト自体も個人開発の延長で運営していますが、記事を増やすだけでは問い合わせはまったく増えませんでした。読者が「次に何を買えるのか」「何を相談できるのか」まで見えていないと、アクセスはあっても収益には変わらない。これは数字を見てやっと気づいたことです。

逆に、CLAUDE.md・作業ログ・公開前チェックの3つを固定したら、記事やアプリを作る速度がはっきり安定しました。手が止まる日が減ったんです。今は「何を作るか」より先に「何を公開して、何につなげるか」を決めるようにしています。個人開発でいちばん効いたのは、賢いAIを探すことではなく、続けられて公開までいける手順を自分の外側に固定したことでした。

実務寄りにもっと使い込みたい方は、生産性を上げるTipsやCLAUDE.mdの設計も参考になります。チーム導入や社内研修を考えている場合は、Claude Code研修・相談で具体的に相談できます。まずは今週末、1画面のMVPを「公開」までやってみてください。完成度より、公開した回数のほうが効きます。