Claude Codeで個人開発を完全自動化する構成（壁打ち→実装→デプロイ→SNS）

「Claude Codeで開発を完全自動化する」とは、要件定義・実装・レビュー・デプロイ・SNS運用までをAIエージェントに任せ、人間は方針決定と最終承認だけを担う開発体制を指します。 本記事は、実際に4つのプロダクトと公式サイトを「1人＋AIエージェント」で運用している立場から、具体的な工程・使用ツール・実際の限界までを公開する一次体験の記録です。抽象論ではなく、今日この文章を配信している仕組みそのものを説明します。

完全自動化とは何を指すか

ここでの「完全自動化」は、コード生成の自動化だけではありません。プロダクト開発の一連の工程——①壁打ち（コンセプト探索）②要件定義 ③設計 ④ツール選択 ⑤実装 ⑥コードレビュー ⑦デプロイ ⑧記事執筆 ⑨SNS配信——のそれぞれを、AIエージェントが実行できる状態にすることを指します。

人間（開発者）の仕事は2つに絞られます。「何を作るか」の方針決定と、後戻りできない操作（本番公開・課金）への最終GOです。この2点以外は、原則としてエージェントに委ねます。

この線引きには理由があります。コードの修正や記事の書き直しは、間違えても次の作業で直せます。エージェントが誤っても、レビューや実機検証で見つけて戻せばよい領域です。一方、本番公開や課金は、実行した瞬間に読者や利用者へ影響が届き、あとから取り消せません。「戻せるかどうか」で任せる範囲を決めておくと、自動化する工程を増やしても、取り返しのつかない判断だけは人間の手元に残ります。

実際の構成：9工程をどう自動化しているか

私たちの現在の構成を、工程ごとに公開します。すべて実運用中のものです。

• 壁打ち・設計: 対話でコンセプトと要件を固め、そのままドキュメント（docs/）に固定。設計判断はログに残す
• 実装・レビュー: Claude Code がコードを書き、別のAIエージェントが独立してレビュー（二重チェック）
• 実機検証: Playwright で本番アプリを操作し、E2Eテスト・スクリーンショット・画面録画を自動取得
• GUI操作: APIの無い操作は Computer Use（デスクトップ自動操作）で補完
• デプロイ: git push で Vercel が自動デプロイ。本番の応答コードを curl で確認
• 記事・SNS: 生成した記事を公式サイトへ、動画・画像を生成して各SNSへ自動配信

各工程は、前の工程の成果物が次の工程の入力になる形でつながっています。壁打ちで固めた要件は docs/ に書かれ、実装を担当するエージェントはそれを読んでからコードを書きます。書かれたコードは、実装したエージェントとは別のエージェントが読み、見落としを指摘します。レビューを通ったものは Playwright で本番アプリとして実際に操作され、スクリーンショットや画面録画が「動いた証拠」として残ります。

デプロイは git push を起点に Vercel が自動で行うため、エージェントが特別な操作をする必要はありません。その代わり、公開後に本番の応答コードを curl で確かめるところまでを1つの工程として扱います。「push した」ではなく「本番が応答した」を完了の条件にしておけば、反映されたかどうかを人間が見に行く必要がなくなります。

実測として、このブログ記事の執筆・検証・公開・SNS告知までの一連が、人間の手作業ゼロで完了します。今日一日で、停止していたデータベースの復旧、SNS自動投稿基盤の構築、動画生成パイプライン、記事の自動公開エンジンを、すべてエージェント主導で立ち上げました。

AIに仕事を「分解して渡す」技術

完全自動化の核心は、コードを速く書くことではなく、AIエージェントに仕事を分解して渡す設計にあります。1人でプロダクト4つ＋サイト＋SNS運用が回るのは、開発者が優秀だからではなく、渡し方が上手くなっただけです。

具体的には次の3点が効きました。

1. ドキュメントを唯一の真実源にする: 方針・制約・品質基準を docs/ に固定し、エージェントは毎回それを読んでから作業する
2. 品質ゲートを明文化する: 「ビルド緑・独立レビュー・実機スモーク・即時記録」の4点を全作業の通過条件にする
3. 並列で走らせる: 独立したタスクは複数エージェントに同時に投げ、結果だけを受け取る

1つ目の「ドキュメントを唯一の真実源にする」は、エージェントが会話の記憶に頼らないための仕組みです。前回のやり取りを覚えている前提で指示を出すと、作業のたびに前提がぶれます。方針・制約・品質基準をファイルとして固定し、作業の最初に読ませれば、どのエージェントが担当しても同じ前提から始められます。

2つ目の品質ゲートは、「終わった」の定義をそろえるためのものです。ビルドが緑になること、書いたものとは別のエージェントが独立にレビューすること、実機で最低限の操作が通ること（スモーク）、結果をすぐに記録すること。この4点を通らない作業は完了扱いにしません。基準が文章になっていれば、エージェント自身が通過を確かめられ、人間は結果だけを見れば済みます。

3つ目の並列化は、1つ目と2つ目が整って初めて効きます。前提がドキュメントにあり、完了の条件が決まっているからこそ、互いに独立したタスクを複数のエージェントへ同時に渡しても、戻ってきた結果を同じ物差しで判断できます。前提と完了条件が曖昧なまま並列にすると、結果の食い違いを人間が一つずつ調べることになり、かえって手間が増えます。

Anthropic は Claude Code を「ターミナル上で動作するエージェント型コーディングツール」と位置づけています（公式ドキュメント(新しいタブで開く)）。この「エージェント型」という性質が、単なる補完ツールとの決定的な差です。

失敗と限界：人間が握り続けている領域

正直に、うまくいかなかった点と、意図的に自動化していない領域も記録します。

• 利用枠がボトルネックになる: 開発をAIに全部任せると、今度は「AIの利用枠」そのものが律速になります。実際に週間の上限を土日で使い切りました
• GUI自動操作は不安定: Computer Use はアプリによって挙動が安定せず、APIがある操作は必ずAPIを優先すべきです
• 後戻りできない操作は人間が承認: 本番公開・課金・法務判断は自動化しません。これは技術的制約ではなく、意図的な設計です

利用枠の問題は、自動化が進んだ結果として現れた新しい制約です。人間の作業時間ではなく、AIに渡せる仕事の量が上限になるため、どのタスクを先に回すかという優先順位づけが以前より重要になりました。GUI自動操作についても、同じ操作をAPIで行えるならAPIを選び、Computer Use はAPIが無い操作の補完にとどめる、という順序を守っています。

「AIが賢いほど、倉庫（＝土台の設計）が正しくできているかが効いてくる」——これが半年運用しての実感です。関連して、6日間で1プロダクトを本番公開した記録はこちらの記事にまとめています。

よくある質問

Q. 非エンジニアでも完全自動化はできますか？ A. 工程の全自動化はハードルが高いですが、「壁打ち→実装→デプロイ」までなら、方針を言語化できれば非エンジニアでも到達可能です。最初は小さなツールから始めるのが現実的です。

Q. コストはどれくらいかかりますか？ A. インフラは無料枠中心で実費をほぼゼロに抑えられます。主なコストはAIの利用料（サブスクリプション）で、開発量に応じて利用枠が律速になります。

Q. コードの品質は担保できますか？ A. 単一のエージェントに任せきりにせず、独立した別エージェントによるレビューを挟むこと（二重チェック）で、見落としを大きく減らせます。

Q. どのツールから始めるべきですか？ A. エージェント型のコーディングツール（Claude Code 等）を軸に、実機検証に Playwright を組み合わせるのが、投資対効果の高い出発点です。

まとめ

• 人間は「何を作るか」の方針決定と、本番公開・課金など後戻りできない操作への最終GOだけを担い、それ以外の工程はエージェントに任せる
• 核心は、ドキュメントを唯一の真実源にし、品質ゲート4点を明文化し、独立したタスクを並列に渡す「仕事の分解」にある
• 限界は利用枠が律速になることとGUI自動操作の不安定さで、APIがある操作は必ずAPIを優先する